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