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>