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