jsr366-experts@javaee-spec.java.net

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

From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
Date: Sat, 24 Jan 2015 20:17:49 +0100

Please, let's stop trying to add "new cool features" into CDI, otherwise we
will have a new "EJB spec".

Antonio

On Sat, Jan 24, 2015 at 7:18 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:

> 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.
>
> wdyt?
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-24 19:08 GMT+01:00 Antonio Goncalves <antonio.goncalves_at_gmail.com
> >:
> > 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 <arjan.tijms_at_gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> On Sat, Jan 24, 2015 at 11:48 AM, Antonio Goncalves
> >> <antonio.goncalves_at_gmail.com> 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. https://developer.ibm.com/wasdev/blog/tag/raspberrypi
> >>
> >> 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 zeef.com and before that m4n.nl 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
>



-- 
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>