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