Ill answer tonight with samples - sorry from phone ATM. I just say
container api is already here in servlets for instance or would be hard to
use if more generic and im not sure it answers your needs.
Le 18 janv. 2015 13:20, "Antonio Goncalves" <antonio.goncalves_at_gmail.com>
a écrit :
> 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>
>