[javaee-spec users] [jsr342-experts] Re: Re: Re: Re: Modularization Framework/SPI

From: Jeff Genender <>
Date: Thu, 26 Jul 2012 09:19:36 -0500


I don't get the support for the marketing drivel. We all come from
different backgrounds. Be it Jboss modules, OSGI, roll your own, or
whatever. If you want data, go look at the Jboss modules, Geronimo
(Websphere CE), Glassfish, Equinox, Karaf, Felix user mailing lists and the
number of blogs on the subject. Go do your own count of users... That's
*not* marketing... Thats *not* anecdotal... That's our users. That is who
we represent. That's *real* data. guess what... They *use* our designs.
Let's please stop the BS at this point. This is a dead horse. If you have
something useful to contribute, please do it...but let's stop the +1s on
the loaded marketing material.

Sent from my iPhone

On Jul 26, 2012, at 9:04 AM, Reza Rahman <> wrote:

 +1 (and I can guarantee that I'm a dispassionate observer on this one :-)).

On 7/26/2012 8:23 AM, Jevgeni Kabanov wrote:

I'm glad we agree on the sentiment.

 The paper is NOT based on customer data. This was a community-wide poll
with 1450+ answers. It agrees with other larger polls, e.g. one conducted
by Eclipse. It certainly is not my side of the fence, it's what the world
looks like, at least in the outline.

 My point was that OSGi adoption is fairly low, and it's the poster-boy of
Java modularity story. Is there an actual need outside the largest shops?
Can we accommodate the largest shops in the spec without impacting the
majority of the community? These are important questions that need
answering before we commit to any one solution.


Founder & CEO of ZeroTurnaround
@ekabanov | Skype: ekabanov |

On Thursday, 26 July 2012 at 15:17, Jeff Genender wrote:


 I have to disagree vehemently with your fist comment. Your presentation of
your paper is strawman. Your paper/analysis is from your customers which is
your side of the fence. You have a small slice of a different sort of
customer and your survey is directed at people who use JRebel and its likes
which is anti OSGi in nature. Different strokes for different folks but I
am certainly not calling yours anecdotal... just strawman. ;-)

 I wasn't stating OSGi is the end-all. But it does fit a need for what
people want form what *I* see. People want the same thing with LiveRebel.
 The areas I listed is what LiveRebel helps to define as well.

 Hence, what you produce is exactly what I want and what your last
statement pretty much summed up. We need something that allows someone to
plug in whatever modular system for now, be it OSGi, JBoss Modules, or even
LiveRebel. You stated exactly what I want to see.


 On Jul 26, 2012, at 6:57 AM, Jevgeni Kabanov wrote:

 This all is very anecdotal. In our survey most folks did not indicate that
they use OSGi or anything like it:
(only a third are our customers, the rest just the folks across the
community that responded)

 There were also a bunch of open questions and although the no downtime
provisioning of application is a great concern, there were fairly little
issues with multiple library version. And modularity without a good
isolation model is not a way to solve hot update or the class loading
issues you mentioned.

 I'm afraid we're trying to solve the issues of the largest shops, which
are always more complex than the rest and probably do need a custom
solution built on OSGi or whatnot. And they already have access to OSGi on
the Glassfish, Websphere and so on.

 Wouldn't it make more sense to accommodate OSGi as an optional extension
of the spec and just define better interoperation? I'm afraid that baking
modularity into the Java EE spec will introduce more complexity than it's
worth for most of the Java EE ecosystem.


Founder & CEO of ZeroTurnaround
@ekabanov | Skype: ekabanov |

On Thursday, 26 July 2012 at 14:41, Jeff Genender wrote:

  Hi Craig... thanks for the response and I darned well agree with a lot in
this email ;-)

 answers in line...

 On Jul 25, 2012, at 7:30 PM, Craig Ringer wrote:

  On 07/25/2012 09:53 PM, Jeff Genender wrote:

In my world, I am seeing users pushing modularity in front of JavaEE and we
are really missing this boat. A large section of my clients are moving to
OSGi stacks picking and choosing what they want in their stacks, with some
building their own JavaEE light containers (JTA, JPA).

 Can you explain in a bit more detail what problems they're encountering
that leave them forced to take this option? Application and business
problems, not just the common "we need X because we've always used it"
issues I see come up sometimes.

 Here are what I usually hear:

 1) The comments made come along the line of the thick stack and having
resources used by major components that aren't used. Complaint is EE-bloat.
2) Ability to hot deploy/undeploy without corrupting the classloaders.
Example... try to deploy/deploy a war many times in a standard JavaEE
container until an OutOf Memory exception occurs.
3) Ability to provision applications and services on the fly without having
to reboot - think cloud-like Applications As A Service (AaaS).
4) Ability to prevent class clashing with multiple versions. Wanting to run
multiple applications in the same container without worry for parent
classloading corruption - the class tree classloading issues.
5) Dependent execution. The ability to run transitive dependencies on other
applications/jars, much like a Unix inti.d or Windows services model. i.e.
an application can;t run until its other dependent applications are running.

 OSGi seems to wor in this model, albeit with a great amount of pain.

 Do you have people who really must swap out the JTA implementation in a an
app server with a different one in order to meet business or application
requirements? JPA I fully understand, but JTA? I'm surprised and interested
by that.

 Yes, many of my clients are interested in the Blueprint JTA implementation
or use a local resource like Spring. Hence those who want to use Spring
local transactions can rip out the JTA, or if they need XA, they wire up
Aries/Blueprint and enable aries-transaction. I see this choice a lot.

 I'm having very frustrating problems with the lack of plugability of some
of the upper layer stuff myself. Hibernate is a very poor fit for the needs
of an app I'm working on, but getting EclipseLink to integrate well into
AS7 is a major pain. I appreciate the need for pluggability at least at the
higher levels of the stack, and it's been a major source of pain for me
since I started working with Java EE.

 My comments were specific to CDI and some low level, tightly integrated
components in the server like the EJB3 implementation, JTA, JCA, etc. These
are tightly integrated and - from what I've seen in AS7's sources and on
the bug tracker - the existing SPIs appear inadeaute to allow them to
simply be swapped out and replaced. I'd *love* to be wrong about this, but
my experience even trying to swap out theoretically pluggable things like
JPA implementations argues against it.

 I would like to see a certain baseline of infrastructure locked in place
as something thatthe app server does not have to support replacing (it
still may if it chooses). In exchange, certain higher level components like
JSF2, JPA2, maybe JAX-RS, etc would *have* to support being swapped out
with either app-bundled implementations or modules installed in the app
server. This would give vendors realistic test targets and narrow the
number of configurations to something (almost) testable. It would also make
it clearer which specs need really complete SPIs as a priority.

 As for needing a module system: I could not possibly agree more, and think
that things like CDI *should* be modules within the app server - for app
server maintainability and good design. Sure enough you'll see that all the
low level components in AS7 are modules. I just don't think the spec should
require the server vendor to support applications swapping out arbitrary
modules; that needs to be confined to modules implementing specs where
there's a good enough SPI.

 The trouble with the module system issue is that JBoss modules is probably
a bit too basic, and OSGi is (IMO) convoluted and horrible to work with.
There isn't a really good candidate.

 I completely agree with you... but I am just concerned we are going to
miss the boat if we keep putting this off. ;-)


Craig Ringer

 No virus found in this message.
Checked by AVG -
Version: 2012.0.2171 / Virus Database: 2437/5147 - Release Date: 07/22/12