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>