users@javaee-spec.java.net

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

From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
Date: Wed, 6 May 2015 10:27:04 +0200

embedded boot + the config is more than enough

+1

On Wed, May 6, 2015 at 10:08 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:

> if you want to standardize the embedded boot + the config I'm +1, if you
> want to let a user aggregate all implementations he wants I'm -0 cause I'm
> sure it will lead to more issues than advantages in practise and it will
> make EE loosing one of its main benefit: works out of the box.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-05-06 9:58 GMT+02:00 Antonio Goncalves <antonio.goncalves_at_gmail.com>:
>
>> Romain, most of the implementations have been doing "more or less the
>> same" for years ! That's why I'm in favor of standardizing the parts that
>> could be standardized.
>>
>> On Wed, May 6, 2015 at 9:33 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com
>> > wrote:
>>
>>> Hello Antonio,
>>>
>>> More or less the same API exist in TomEE for years (and actually in more
>>> flavors but I'll detail only 2 which I think are linked to this topic):
>>> - tomee-embedded: very close to swarm and payara micro (both features)
>>> even if configuration is a bit different
>>> - ApplicationComposer: coming from testing the idea is to replace the EE
>>> model part by user code (ie to get a persistence.xml you return a
>>> Persistence in a method declared as a @Module and you build it with
>>> something like new Persistence().version("2.0").addUnit(...)). This
>>> replaces the persistence.xml typically. There is API for all part of EE.
>>> This case is interesting because you control of your application
>>> programmatically which is unnatural with EE which is mainly about discovery.
>>>
>>> Now there is something different between your original idea and this:
>>> you register configurations not implementations (not another container in
>>> the meta container). However I think it matches better the way a user need
>>> to write an application using EE.
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com>
>>>
>>> 2015-05-06 9:21 GMT+02:00 Antonio Goncalves <antonio.goncalves_at_gmail.com
>>> >:
>>>
>>>> Looks like RedHat has been one step forward with Swarm :
>>>> http://wildfly.org/news/2015/05/05/WildFly-Swarm-Released/
>>>>
>>>> public class Main {
>>>>
>>>> public static void main(String[] args) throws Exception {
>>>> Container container = new Container();
>>>>
>>>> container.subsystem(new MessagingFraction()
>>>> .server(
>>>> new MessagingServer()
>>>> .enableInVmConnector()
>>>> .topic("my-topic")
>>>> .queue("my-queue")
>>>> )
>>>> );
>>>>
>>>> // Start the container
>>>> container.start();
>>>>
>>>>
>>>> Antonio
>>>>
>>>> On Mon, Dec 22, 2014 at 9:28 PM, Antonio Goncalves <
>>>> antonio.goncalves_at_gmail.com> wrote:
>>>>
>>>>> 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 <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>
>>>>
>>>
>>>
>>
>>
>> --
>> 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>