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