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>