Romain, what Antonio talks about is basically what we have built with Apache DeltaSpike Container Control [1]. It is a single API which allows you to boot up and control any embedded container. Regardless if this is just pure CDI (OpenWebBeans or Weld) or a fully blown embedded EE container like openejb-embedded or jbossas-embedded.
This is perfectly working since many years, but sadly it is not a standard yet.
We are also currently thinking about a SE module in the CDI EG but it really is much more - it should be a way to boot up a whole embedded container with EJB, CDI, JPA and JTA for example. This really makes a lot sense!
LieGrue,
strub
[1]
http://deltaspike.apache.org/documentation/container-control.html
On Wednesday, 14 January 2015, 22:32, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
>
>Hehe alternatives are not better just cause you have at least 5 different meanings for "container" so not that sad ;).
>
>Le 14 janv. 2015 22:22, "Antonio Goncalves" <antonio.goncalves_at_gmail.com> a écrit :
>
>> It would require a lot of hooks
>>
>>
>>To be honest, I feel sad to see that Java EE, 15 years old, hasn't been able to standardize a Container API... it seems unreal...
>>
>>
>>Antonio
>>
>>
>>
>>
>>
>>
>>On Wed, Jan 14, 2015 at 8:11 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
>>
>>Well meta container or generic container are quite hard to define. It would require a lot of hooks - even only considering cdi, servlet and ejb for instance. I really think it will make it abandonned before being used cause hard to implement and actually rarely portable.
>>>However only defining more profiles would be a good alternative and hurtless IMO (batch, processing, desktop...).
>>>
>>>Le 14 janv. 2015 05:14, "Reza Rahman" <Reza.Rahman_at_oracle.com> a écrit :
>>>
>>>
>>>If I'm not mistaken I think this is the basics of what Antonio is talking about: https://java.net/jira/browse/JAVAEE_SPEC-27. It was on the EE 8 survey, but unfortunately had a poorer showing in the prioritization survey (though it did make it to the prioritization survey).
>>>>
>>>>On 1/12/2015 3:31 PM, Antonio Goncalves wrote:
>>>>
>>>>I'm talking about *a* container, where everything works. At the moment, if you have an @Inject in an EntityListener and use the EntityManager in SE, it won't work. This is very confusing for developers (why @Entity works but not @Inject ?). Java EE needs a single container API where every combination of spec would work !
>>>>>
>>>>>
>>>>>Antonio
>>>>>
>>>>>
>>>>>On Mon, Jan 12, 2015 at 9:05 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
>>>>>
>>>>>Why having a meta api? Why not having one container by spec needing it - I agree a WebContainer and CdiContainer for instance would be useful, not sure for a BatchContainer ATM?
>>>>>>Le 12 janv. 2015 20:14, "Antonio Goncalves" <antonio.goncalves_at_gmail.com> a écrit :
>>>>>>
>>>>>>
>>>>>>A "Container" API would be a very good first step (remember that we have an EJBContainer API that is not *that* useful and no WebContainer API)
>>>>>>>
>>>>>>>
>>>>>>>On Mon, Jan 12, 2015 at 8:08 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
>>>>>>>
>>>>>>>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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
--
>>>>>>>
>>>>>>>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
>
>