users@javaee-spec.java.net

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

From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: Sat, 24 Jan 2015 20:22:29 +0100

@Antonio: never asked such a thing. Just proposed to use CDI 2 as base
for the EE container you speak about. An event to create resources, an
event to define programmatically a persistence unit etc...


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-01-24 20:17 GMT+01:00 Antonio Goncalves <antonio.goncalves_at_gmail.com>:
> 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France