[jsr366-experts] Re: [javaee-spec users] Re: Re: One container to rule them all

From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
Date: Tue, 10 Mar 2015 11:14:52 +0100

Hi all,

This serie of blog posts from Mark Little is quite interesting. Mark has
his point of view on containers, but does not hesitate to write loud what
others think ("container-less movement", "moving away from containers seems
to be the theme of the day", "containers are bad for agile development" or
"containers are not fit for modern web apps"). One sentence is also
interesting "mobile developer, Cloud or the Internet of Things. In short,
these technology waves represent the death of middleware"


And interesting answer back to his posts.


We've all went through the SQL-NoSQL or the SOAPWS-RestWS era. IT is
sometimes about fashion, and sometimes about technological shift. IoT,
Microservices, Docker... can either be buzzwords, or can be the future. If
JavaEE does not take a guess now and makes some moves, we might help the
"container-less" movement.

I still think bootstraping a JavaEE container with an API is needed... and
of course, modularise it.


On Fri, Feb 20, 2015 at 10:54 PM, David Blevins <dblevins_at_tomitribe.com>

> The EJBContainer API is definitely used, but I suspect usage drastically
> varies server to server. It's a staple in the OpenEJB crowd. I think the
> major thing to take away from it is how much have things changed since it
> was added. All the vendors were forced to take a serious look at how to
> slim down their installs and peal out that component to meet the
> requirement. This, along with Arquillian, incited great progress in the
> size and startup time of the main servers.
> We need more of this in the market.
> On Feb 20, 2015, at 8:11 AM, Antonio Goncalves <
> antonio.goncalves_at_gmail.com> wrote:
> > Take @Stateless and replace it with a @Transactional, and that's the end
> of the EJBContainer API. Either we update it with the new improvements of
> Java EE 7 and 8, or we leave it. Nobody uses the EJBContainer in "real"
> applications, not even for testing as we quickly can't make it work with
> other specs. A Container that is allowed to orchestrate all the other
> specs, makes sense, if it's only a subset (like the EJBContainer) then it
> will not be used.
> >
> > Except for the front-end technologies (JSF and JSP) I would like to have
> a Container API to rule them all.
> >
> > Antonio
> >
> > On Fri, Feb 20, 2015 at 4:55 PM, David Blevins <dblevins_at_tomitribe.com>
> wrote:
> >
> > On Feb 20, 2015, at 7:20 AM, Antonio Goncalves <
> antonio.goncalves_at_gmail.com> wrote:
> >
> > > and is completely useless today
> >
> > Careful about that. Bill's biggest concern with Java EE in general is
> adding things which immediately become failed and legacy.
> >
> > That statement will read, "we couldn't figure out how to make an EJB
> Container API people wanted, let's take our lack of skill and make a
> Container API."
> >
> > They frequently let the sub-specs have a little creative freedom as a
> way to test interest and the market for ideas that might make sense
> platform wide.
> >
> > If the EJB Container API is successful. More will come.
> >
> > If it was failed. The train stops entirely.
> >
> >
> > -David
> >
> >
> >
> >
> > --
> > 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> |
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>