Back on a computer, let's try to dig into your needs and see what I
didnt fully get from your description:
"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)."
So your needs are
1) shades
2) cloud
3) embedded mode (1 is then an under item of 3)
About 1: no API can solve it but strict constraints on packaging are
mandatory (think to SPI using META-INF/services how to merge them
through an API -> no way). Then a boot API can help making it easy to
write but is far to be the blocker
About 2: what's the need? AFAIK only thing EE doesnt support for cloud
is environment (linux "exports" for instance) integration -> this is a
placeholder need AFAIK. What do you think about here?
About 3: I agree an embedded mode could be standardized, why not using
CDI for it since we'll get a standard CDI API for this pupose?
EJBContainer is here and most of containers support all their features
through it but if you think EJB are dead then CDI should be the
backbone, no?
What does miss? a fully programmatic API - which is not yet a meta
container API where you can describe your app programmatically more or
less (something between openejb application composer and spring boot I
guess).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-18 13:22 GMT+01:00 Simon Martinelli <simon.martinelli_at_gmail.com>:
> +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 | 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 | 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