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

From: Romain Manni-Bucau <>
Date: Sat, 24 Jan 2015 19:18:12 +0100

fully agree with it but I still think your solution is one potential
and that the topic started with a solution instead of a need.

If you look what is used the most today you have mainly 2 kind of
apps: war and main(String[]). What's the common point? Globally both
shares a flat classloader in terms of development/user and it is
opposed to modularity at deployment level (which doesnt mean it doesnt
have modularity at software level. That's why I still think these new
needs you speak about needs to be addressed but not with a meta
container but rather with more container events in CDI - or even
something lower than CDI. In other words CDI used itself as backbone
of its configuration/extensibility so why not using same kind of
programmatic approach for all specs. Then once CDI has a standalone
standard boot all containers have it. So you meta container becomes
CDI and we avoid another generic solution which would end up as ears =
a lot of constraints and issues for few gains.


Romain Manni-Bucau

2015-01-24 19:08 GMT+01:00 Antonio Goncalves <>:
> I love this sentence "it's essentially the app that owns the AS"
> Antonio
> On Sat, Jan 24, 2015 at 6:00 PM, arjan tijms <> wrote:
>> Hi,
>> On Sat, Jan 24, 2015 at 11:48 AM, Antonio Goncalves
>> <> wrote:
>> > We can't keep on saying "Java EE is just for fat *real*
>> > application, use something else for your IoT developments".
>> I strongly agree with this.
>> This comes up often in discussions about Java EE; the idea about
>> *real* applications or the *one and only right way*.
>> In that vision, which originated in J2EE, there's always a somewhat
>> untrusted team of developers and a trusted team of Ops. The
>> Application Server is installed once, and developers are not even
>> allowed near it. The Ops team maintains the server and all
>> "resources", such as data sources, JMS destinations, thread pools and
>> security modules. The developers are not allowed to create any of
>> those resources themselves, and *at most* are allowed to put a comment
>> or readme.txt somewhere, which the Ops team is then to interpret in
>> some way (which is a often brittle) and if the team is lucky, create
>> the resource in the right way (and if the team is unlucky, weeks or
>> even months of creating tickets can be needed to get a trivial task to
>> be done).
>> Nothing can ever be upgraded in this vision, since there are always at
>> least 10 totally different applications running on said AS, and it's
>> always impossible to update or test at least a few of those. IMHO the
>> idea that "Java EE can't be upgraded" has its roots in this vision.
>> The vision also talks about roles like bean providers, application
>> assemblers, application deployers etc.
>> Even if there are indeed places that work like this, it's by far not
>> the only way. Indeed, for IoT deployments, where I have a lightweight
>> AS with a small app for home automation deployed to a raspberry pi,
>> this somewhat mandatory assumed division of roles does not make any
>> sense at all. In that case there is no untrusted developer and trusted
>> ops, since there's only me. There's no need to define a data source
>> outside the application and provision a database for which the
>> password needs to be hidden from the untrusted developer, since
>> there's only a tiny embedded H2 database, etc.
>> It's funny perhaps that IBM, which is maybe most known for its very
>> large WebSphere installations and its many tools for supporting the
>> mentioned old J2EE vision, is also the one creating a lightweight Java
>> EE runtime (Liberty) that does focus greatly on being suitable for
>> IoT. See e.g.
>> But even for somewhat more traditional usages of Java EE, such as a
>> web app, the strict dev/ops division and the single installed AS is
>> not a given at all. At and before that the AS is
>> basically just a library to us. We keep its source in our git repo,
>> and whenever anything changes to it we can deploy it just as we would
>> deploy an application archive (war/ear). Since we have a strict rule
>> of 1 application per AS and can trivially deploy a new or modified
>> version of the AS, it's essentially the app that owns the AS, instead
>> of the other way around.
>> Long story short; having a "java -jar javax.enterprise.Container
>> command" deployment model would fit a lot of alternative use cases. A
>> fixed monolithic installed AS that's shielded from developers is
>> absolutely not the only viable model.
>> Kind regards,
>> Arjan Tijms
>> >
>> >
>> >> On the other hand, note that the Java EE specification is composed of a
>> >> large number of other specifications, most of which are defined to work
>> >> on
>> >> Java SE with few dependencies on the others. You can build a runtime
>> >> by
>> >> combining implementations of many of these specifications. You might
>> >> be
>> >> missing many of the common facilities defined by the Java EE platform
>> >> specification, but for simple applications that might be good enough.
>> >
>> >
>> >
>> > Java SE modularization is a bet on the future (create your own JVM with
>> > your
>> > needed modules) we must do the same for Java EE. I know it's a huge
>> > effort
>> > for implementors, but it's the only exit for Java EE if we want it to be
>> > alive in 10 years (and when I say alive, it's not about keeping old
>> > applications up and running, it's thinking about Java EE everywhere, in
>> > a
>> > Linux environment, in a mobile phone, in a fridge...). "Java EE
>> > specification is composed of a large number of other specifications".
>> > Exactly, that's why we must go further. The Java EE contract should be
>> > "bundle the specs you need, we make sure they all work together, link
>> > them
>> > all together, build your own app server, and deploy it in a chip in your
>> > fridge with just a java -jar javax.enterprise.Container command".
>> >
>> >
>> >> Obviously this will be an interesting discussion to have when we get to
>> >> Java EE 9. We'll be especially interested in what the Java EE vendors
>> >> have
>> >> to say since they will bear the burden of whatever we decide.
>> >
>> >
>> >
>> > Yes, I would like to ear what vendors say. Java EE lost its momentum
>> > years
>> > ago, still hasn't recover from it, we must look into the future. I think
>> > Java EE 8 should start making some steps toward its own modularization
>> > (at
>> > least imposing SPIs and making sure it works in Java SE, and an umbrella
>> > Container API). Profiles are also a first step, but their are not
>> > enough.
>> >
>> > My 2 cents
>> >
>> > --
>> > 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