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 22:30:59 +0100

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 <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>
>>>
>>>
>>>
>
>
> --
> 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>
>