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>