users@javaee-spec.java.net

[javaee-spec users] Re: Fwd: [jsr366-experts] Re: One container to rule them all

From: Reza Rahman <Reza.Rahman_at_oracle.com>
Date: Tue, 13 Jan 2015 23:11:43 -0500

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