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