users@javaee-spec.java.net

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

From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: Wed, 6 May 2015 09:33:08 +0200

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