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: Wed, 11 Feb 2015 15:32:24 +0100

@Peter: not sure what you wanted to add. I really agree with that
statement but it doesnt mean we need a meta container. That's even the
opposite: we need CDI and that's what i said as well.


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


2015-02-11 15:28 GMT+01:00 Peter Pilgrim <peter.pilgrim_at_gmail.com>:
> Hi Romain
>
> If I could, I would like to channel in David Blewin, here.
>
> Almost two years ago, David and I had a hallway conversation at Devoxx UK,
> about the relationship between general CDI beans and EJB session beans.
> David said that there is fundamentally very small differences between these
> object instances CDI Pojos and EJBs. They essentially are living on two
> different Map<K,Object> instances as far as the server is concerned. He
> posited the thought that EJB session beans should have been renamed as
> ``pool-able transactional and container scoped'' beans.In other words, there
> is no difference between CDI and EJB, except there is a secret scope
> @ContainerScoped that exists in the implementation.
>
> What needs to happens is to take the work from SpikeDelta for CDI and extend
> it to EJB and Web containers?
>
> Somebody will also need to build it into the reference implementation
> product (Glassfish) as a proof of concept. Has SpikeDelta been extended for
> GlassFish CDI container?
>
>
>
> 2 pence
>
>
> On 24 January 2015 at 19:22, Romain Manni-Bucau <rmannibucau_at_gmail.com>
> wrote:
>>
>> @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
>
>
>
>
> --
> Best wishes
>
> Peter Pilgrim,
> Java Champion
>
> ++++ Scala and Java EE Software Development / Design / Architect for
> `BlueChip' enterprises, London, UK ++++
>
> I am the author of ``The Java EE 7 Developer Handbook'' Packt Pub
> (September 2013)
> http://www.packtpub.com/java-ee-7-developer-handbook/book
> I am currently writing ``Digital Java EE 7 Development'' Packt Pub (May
> 2015)
>
> ++++ Digital ++ Finance ++ Adaptation ++ Transformation ++ Software ++++
>
> :: http://www.xenonique.co.uk/blog/ ::
> :: http://twitter.com/peter_pilgrim ::
> :: http://java-champions.java.net/ ::
> :: Skype Call peter_pilgrim ::
> :: http://audio.fm/profile/peter_pilgrim ::