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>