+1 for the container API proposed by Antonio
Am 18.01.2015 13:20 schrieb "Antonio Goncalves" <antonio.goncalves_at_gmail.com
>:
> Difficult to understand your point of view and why a Container API
> shouldn't be standardized.
>
> Antonio
>
> On Sun, Jan 18, 2015 at 1:06 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com
> > wrote:
>
>> Not modularity bug ready to run solutions which is the opposite.
>>
>> All other approches you speak about exist today and can be normalized but
>> this doesnt imply a container api like the one you described AFAIK.
>> Le 18 janv. 2015 12:23, "Antonio Goncalves" <antonio.goncalves_at_gmail.com>
>> a écrit :
>>
>> What's the point of defining more profiles ? More modularity ? It will
>>> come with EE 9. With a Container API, I could even create executable jars
>>> and just start an entire app with a java -jar MyApp. We also have to
>>> think about future approaches, cloud, deployment and so on. We need to be
>>> able to start an app server, deploy an app... but also allow EE developers
>>> to just quickly bootstrap an application (with the embedded container).
>>>
>>> The world of the app server is changing, let's go one step further.
>>>
>>> Antonio
>>>
>>> On Wed, Jan 14, 2015 at 10:30 PM, 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 <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>
>>>
>>
>
>
> --
> 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>
>