Well most of impl makes it working guessing environment when possible.
That said if all containers implements the same API (Container) and
supports @Priority it should be doable but wonder if it would really
make it usable and easy.
any other opinion?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-12 21:31 GMT+01:00 Antonio Goncalves <antonio.goncalves_at_gmail.com>:
> 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 | 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