this is not what I got at all. Starting a container and being able to
use what it packages or being able to compose its own container from
several ones are really different.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-24 19:27 GMT+01:00 Mark Struberg <struberg_at_yahoo.de>:
> Romain, what Antonio talks about is basically what we have built with Apache DeltaSpike Container Control [1]. It is a single API which allows you to boot up and control any embedded container. Regardless if this is just pure CDI (OpenWebBeans or Weld) or a fully blown embedded EE container like openejb-embedded or jbossas-embedded.
>
> This is perfectly working since many years, but sadly it is not a standard yet.
>
> We are also currently thinking about a SE module in the CDI EG but it really is much more - it should be a way to boot up a whole embedded container with EJB, CDI, JPA and JTA for example. This really makes a lot sense!
>
>
>
> LieGrue,
> strub
>
>
> [1] http://deltaspike.apache.org/documentation/container-control.html
>
>
> On Wednesday, 14 January 2015, 22:32, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
>>
>>Hehe alternatives are not better just cause you have at least 5 different meanings for "container" so not that sad ;).
>>
>>Le 14 janv. 2015 22:22, "Antonio Goncalves" <antonio.goncalves_at_gmail.com> a écrit :
>>
>>> It would require a lot of hooks
>>>
>>>
>>>To be honest, I feel sad to see that Java EE, 15 years old, hasn't been able to standardize a Container API... it seems unreal...
>>>
>>>
>>>Antonio
>>>
>>>
>>>
>>>
>>>
>>>
>>>On Wed, Jan 14, 2015 at 8:11 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
>>>
>>>Well meta container or generic container are quite hard to define. It would require a lot of hooks - even only considering cdi, servlet and ejb for instance. I really think it will make it abandonned before being used cause hard to implement and actually rarely portable.
>>>>However only defining more profiles would be a good alternative and hurtless IMO (batch, processing, desktop...).
>>>>
>>>>Le 14 janv. 2015 05:14, "Reza Rahman" <Reza.Rahman_at_oracle.com> a écrit :
>>>>
>>>>
>>>>If I'm not mistaken I think this is the basics of what Antonio is talking about: https://java.net/jira/browse/JAVAEE_SPEC-27. It was on the EE 8 survey, but unfortunately had a poorer showing in the prioritization survey (though it did make it to the prioritization survey).
>>>>>
>>>>>On 1/12/2015 3:31 PM, Antonio Goncalves wrote:
>>>>>
>>>>>I'm talking about *a* container, where everything works. At the moment, if you have an @Inject in an EntityListener and use the EntityManager in SE, it won't work. This is very confusing for developers (why @Entity works but not @Inject ?). Java EE needs a single container API where every combination of spec would work !
>>>>>>
>>>>>>
>>>>>>Antonio
>>>>>>
>>>>>>
>>>>>>On Mon, Jan 12, 2015 at 9:05 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
>>>>>>
>>>>>>Why having a meta api? Why not having one container by spec needing it - I agree a WebContainer and CdiContainer for instance would be useful, not sure for a BatchContainer ATM?
>>>>>>>Le 12 janv. 2015 20:14, "Antonio Goncalves" <antonio.goncalves_at_gmail.com> a écrit :
>>>>>>>
>>>>>>>
>>>>>>>A "Container" API would be a very good first step (remember that we have an EJBContainer API that is not *that* useful and no WebContainer API)
>>>>>>>>
>>>>>>>>
>>>>>>>>On Mon, Jan 12, 2015 at 8:08 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
>>>>>>>>
>>>>>>>>I got the idea but isnt it already the case since spec are integrated
>>>>>>>>>between them? JBatch doesn't need a EE
> container it is just provided
>>>>>>>>>by EE but well defined in SE. Introducing
> such a container you stay
>>>>>>>>>full EE to keep this provided spirit so next
> question will be "I don't
>>>>>>>>>want a dependency I dont need" so you are
> back in SE. Did I miss
>>>>>>>>>something here?
>>>>>>>>>
>>>>>>>>>Not sure it does worth spending time on it
> *now* as you mentionned it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Romain Manni-Bucau
>>>>>>>>>@rmannibucau
>>>>>>>>>http://www.tomitribe.com
>>>>>>>>>http://rmannibucau.wordpress.com
>>>>>>>>>https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>2015-01-12 19:59 GMT+01:00 Antonio Goncalves <antonio.goncalves_at_gmail.com>:
>>>>>>>>>> Modularization is not the main
> topic to be honest, Java EE will be
> modular
>>>>>>>>>> once Java SE is. So I don't worry
> about this.
>>>>>>>>>>
>>>>>>>>>> I'm more concerned about this
> entire idea of having an EJB container
> (while
>>>>>>>>>> the EJB spec is losing momentum)
> and a Web Container (while JBatch is
> part
>>>>>>>>>> of EE and doesn't need any web).
>>>>>>>>>>
>>>>>>>>>> So, what about introducing a single
> container that does everything that is
>>>>>>>>>> needed ? And an API so EE could be
> configured and triggered from SE ?
>>>>>>>>>>
>>>>>>>>>> Any thoughts ?
>>>>>>>>>>
>>>>>>>>>> Antonio
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 7, 2015 at 8:28 AM,
> Romain Manni-Bucau <rmannibucau_at_gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Seems this message was bounced
> to Linda, sorry Linda and fwding it to
>>>>>>>>>>> the right list.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------- Forwarded message
> ----------
>>>>>>>>>>> From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
>>>>>>>>>>> Date: 2015-01-06 17:39
> GMT+01:00
>>>>>>>>>>> Subject: Re: [javaee-spec
> users] [jsr366-experts] Re: One
> container to
>>>>>>>>>>> rule them all
>>>>>>>>>>> To: jsr366-experts_at_javaee-spec.java.net
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> this is funny to put a SE need
> in EE - in EE all is already assembled
>>>>>>>>>>> so why activating or not
> features through another API? This
> actually
>>>>>>>>>>> looks like the opposite of EE.
>>>>>>>>>>>
>>>>>>>>>>> This kind of API "super
> extensible" is just either too generic
> to be
>>>>>>>>>>> useful in practise or just not
> generic enough to be extended
>>>>>>>>>>> (Container.createWebManager())
> so I'm not sure to get the gain.
>>>>>>>>>>>
>>>>>>>>>>> What would maybe be useful and
> join the underlying need is to be able
>>>>>>>>>>> to assemble an app completely
> programmatically - what all specs try to
>>>>>>>>>>> do - and then skip scanning,
> descriptor discovery etc.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>> @rmannibucau
>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>> http://rmannibucau.wordpress.com
>>>>>>>>>>> https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2015-01-06 17:30 GMT+01:00
> Antonio Goncalves
>>>>>>>>>>> <antonio.goncalves_at_gmail.com>:
>>>>>>>>>>> > I think the Java EE spec
> is the perfect place to have such
> feature !
>>>>>>>>>>> >
>>>>>>>>>>> > Antonio
>>>>>>>>>>> >
>>>>>>>>>>> > On Tue, Jan 6, 2015 at
> 5:25 PM, Antoine Sabot-Durand
>>>>>>>>>>> > <antoine_at_sabot-durand.net> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Form what I
> understand, you're proposing to add a
> new specification to
>>>>>>>>>>> >> provide a facade and a
> common SPI for all the container. Is
> that it?
>>>>>>>>>>> >>
>>>>>>>>>>> >> Antoine
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> Le 22 déc. 2014 à
> 21:28, Antonio Goncalves
>>>>>>>>>>> >> <antonio.goncalves_at_gmail.com> a
>>>>>>>>>>> >> écrit :
>>>>>>>>>>> >>
>>>>>>>>>>> >> Hi all,
>>>>>>>>>>> >>
>>>>>>>>>>> >> We've talked about
> this topic in EE 7... and I'm bringing
> it back to EE
>>>>>>>>>>> >> 8.
>>>>>>>>>>> >>
>>>>>>>>>>> >> At the moment, the
> Java EE spec defines several containers
> (EE.2.4 -
>>>>>>>>>>> >> Containers) : Web
> Container, EJB Container, Application
> Client
>>>>>>>>>>> >> Container and
>>>>>>>>>>> >> Applet Container. Each
> having its own set of services (EE.2.7 -
> Java EE
>>>>>>>>>>> >> Standard Services)
> such as JTA, Validation, CDI... The spec
> also
>>>>>>>>>>> >> defines
>>>>>>>>>>> >> SPIs (EE.2.12.2 - Java
> EE Service Provider Interfaces) as "the
> contract
>>>>>>>>>>> >> between the Java EE
> platform and service providers that may
> be plugged
>>>>>>>>>>> >> into
>>>>>>>>>>> >> a Java EE product".
> But these SPIs are not really mandatory
> (only a few
>>>>>>>>>>> >> specs have SPIs).
>>>>>>>>>>> >>
>>>>>>>>>>> >> Why not go further and
> say "There is a single Java EE
> container, and
>>>>>>>>>>> >> each
>>>>>>>>>>> >> service can then be
> plugged in through a SPI" ?
>>>>>>>>>>> >>
>>>>>>>>>>> >> Let me take an
> example. If we want to persist a Book
> Entity in Java SE
>>>>>>>>>>> >> we
>>>>>>>>>>> >> go :
>>>>>>>>>>> >>
>>>>>>>>>>> >> EntityManagerFactory
> emf =
>>>>>>>>>>> >>
> Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
>>>>>>>>>>> >> EntityManager em =
> emf.createEntityManager();
>>>>>>>>>>> >> EntityTransaction tx
> em.getTransaction();
>>>>>>>>>>> >>
>>>>>>>>>>> >> tx.begin();
>>>>>>>>>>> >> Book book =
> service.createBook(new Book("H2G2"));
>>>>>>>>>>> >> tx.commit();
>>>>>>>>>>> >>
>>>>>>>>>>> >> em.close();
>>>>>>>>>>> >> emf.close();
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> That's fine because
> the JPA service does persistence. But if
> the Book
>>>>>>>>>>> >> Entity has a Listener
> with a CDI @Inject, this doesn't work
> anymore :
>>>>>>>>>>> >> you
>>>>>>>>>>> >> need an extra
> injection services that comes from
> another spec (CDI in
>>>>>>>>>>> >> this
>>>>>>>>>>> >> case). The idea behind
> the EJBContainer API was to aggregate
> several
>>>>>>>>>>> >> services (i.e. the
> services given to an EJB component). So,
> to have JPA
>>>>>>>>>>> >> and
>>>>>>>>>>> >> CDI working in Java SE
> we would go :
>>>>>>>>>>> >>
>>>>>>>>>>> >> Map<String,
> Object> properties = new
> HashMap<>();
>>>>>>>>>>> >>
> properties.put(EJBContainer.MODULES, new
> File("target/classes"));
>>>>>>>>>>> >> EJBContainer ec =
> EJBContainer.createEJBContainer(properties);
>>>>>>>>>>> >> Context ctx =
> ec.getContext();
>>>>>>>>>>> >>
>>>>>>>>>>> >> BookEJB bookEJB =
> (BookEJB)
> ctx.lookup("java:global/classes/BookEJB");
>>>>>>>>>>> >>
>>>>>>>>>>> >> ec.close();
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> But if the EJB spec is
> not updated, then the EJBContainer will
> not
>>>>>>>>>>> >> include
>>>>>>>>>>> >> the new services (such
> has the new Security spec, and so on).
>>>>>>>>>>> >>
>>>>>>>>>>> >> So what if the Java EE
> spec would define a single container API
> ?
>>>>>>>>>>> >> Something like this
> would trigger a full Java EE container
> with *all*
>>>>>>>>>>> >> the
>>>>>>>>>>> >> services :
>>>>>>>>>>> >>
>>>>>>>>>>> >> Container eec =
> Container.createContainer();
>>>>>>>>>>> >>
>>>>>>>>>>> >> EntityManagerFactory
> emf =
>>>>>>>>>>> >>
> eec.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
>>>>>>>>>>> >> EntityManager em =
> emf.createEntityManager();
>>>>>>>>>>> >> EntityTransaction tx
> em.getTransaction();
>>>>>>>>>>> >>
>>>>>>>>>>> >> tx.begin();
>>>>>>>>>>> >> Book book =
> service.createBook(new Book("H2G2"));
>>>>>>>>>>> >> tx.commit();
>>>>>>>>>>> >>
>>>>>>>>>>> >> em.close();
>>>>>>>>>>> >> emf.close();
>>>>>>>>>>> >>
>>>>>>>>>>> >> eec.close();
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> Or if we just need the
> JPA + BeanValidation + CDI providers, we
> would
>>>>>>>>>>> >> go :
>>>>>>>>>>> >>
>>>>>>>>>>> >>
> List<Container.PROVIDER>
> properties = new ArrayList<>();
>>>>>>>>>>> >>
> properties.put(PROVIDER.JPA);
>>>>>>>>>>> >>
> properties.put(PROVIDER.BEAN_VALIDATION);
>>>>>>>>>>> >>
> properties.put(PROVIDER.CDI);
>>>>>>>>>>> >> Container eec =
> Container.createContainer(properties);
>>>>>>>>>>> >> //...
>>>>>>>>>>> >> eec.close();
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> To have a Web Profile
> we could go :
>>>>>>>>>>> >>
>>>>>>>>>>> >>
> List<Container.PROVIDER>
> properties = new ArrayList<>();
>>>>>>>>>>> >>
> properties.put(PROVIDER.WEB_PROFILE);
>>>>>>>>>>> >> Container ec =
> Container.createContainer(properties);
>>>>>>>>>>> >> //...
>>>>>>>>>>> >> ec.close();
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> And the Container API
> would become a facade to create any Java
> EE
>>>>>>>>>>> >> provider
>>>>>>>>>>> >> :
>>>>>>>>>>> >>
>>>>>>>>>>> >> EntityManagerFactory
> emf =
>>>>>>>>>>> >>
> Container.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
>>>>>>>>>>> >> CacheManager cache =
> Container.createCacheManager();
>>>>>>>>>>> >> WebManager web =
> Container.createWebManager();
>>>>>>>>>>> >> BeanManager bm =
> Container.createBeanManager();
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> This would bring real
> modularity (even before Java EE 9) and,
> finally,
>>>>>>>>>>> >> would ease Java SE
> execution and testing.
>>>>>>>>>>> >>
>>>>>>>>>>> >> Any thoughts ?
>>>>>>>>>>> >>
>>>>>>>>>>> >> --
>>>>>>>>>>> >> Antonio Goncalves
>>>>>>>>>>> >> Software architect,
> Java Champion and Pluralsight author
>>>>>>>>>>> >>
>>>>>>>>>>> >> Web site | Twitter |
> LinkedIn | Pluralsight | Paris JUG |
> Devoxx France
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > --
>>>>>>>>>>> > Antonio Goncalves
>>>>>>>>>>> > Software architect, Java
> Champion and Pluralsight author
>>>>>>>>>>> >
>>>>>>>>>>> > Web site | Twitter |
> LinkedIn | Pluralsight | Paris JUG |
> Devoxx France
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Antonio Goncalves
>>>>>>>>>> Software architect, Java Champion
> and Pluralsight author
>>>>>>>>>>
>>>>>>>>>> Web site | Twitter | LinkedIn |
> Pluralsight | Paris JUG | Devoxx France
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
> --
>>>>>>>>
>>>>>>>>Antonio Goncalves
>>>>>>>>Software architect, Java Champion and
> Pluralsight author
>>>>>>>>
>>>>>>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> --
>>>>>>
>>>>>>Antonio Goncalves
>>>>>>Software architect, Java Champion and Pluralsight author
>>>>>>
>>>>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>>>>
>>>
>>>
>>>
>>>--
>>>
>>>Antonio Goncalves
>>>Software architect, Java Champion and Pluralsight author
>>>
>>>Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>>
>>