users@javaee-spec.java.net

[javaee-spec users] Re: Fwd: [jsr366-experts] Re: One container to rule them all

From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: Wed, 14 Jan 2015 08:11:33 +0100

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 <http://www.antoniogoncalves.org> | Twitter
>>> <http://twitter.com/agoncal> | LinkedIn
>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>>
>>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>
>
>