users@javaee-spec.java.net

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

From: Mark Struberg <struberg_at_yahoo.de>
Date: Sat, 24 Jan 2015 18:27:05 +0000 (UTC)

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