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