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