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

From: Jeff Genender <>
Date: Wed, 25 Jul 2012 08:53:32 -0500

I have to completely disagree with Craig. JavaEE vendors are implementing
pluggable modular capabilities because its direly needed.

We don't have to design a thorough modular spec now, but something that
gives a bridge to pluggable modularity would be a great direction. A
simple SPI that contains a degree of life cycle would be a good start.

If we keep putting this off, it going to be too late and the landscape for
modularity will be terribly fragmented.

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

Excuse my abrasiveness, but this is key and we just keep making excuses for
putting it off.

Craig, this was certainly not directed at you... Just the nay-sayers as a

Sent from my iPhone

On Jul 25, 2012, at 8:32 AM, Reza Rahman <> wrote:

I must say these are indeed good points…

*From:* Craig Ringer []
*Sent:* Tuesday, July 24, 2012 8:07 PM
*To:* Reza Rahman
*Subject:* Re: [javaee-spec users] [jsr342-experts] Re: Modularization

On 07/24/2012 09:27 PM, Reza Rahman wrote:

You are absolutely correct in that CDI is quite progressive with regards to
extensibility and pluggability into non-Java EE runtimes. I am actually
concerned about pluggability/upgradability within Java EE runtimes. This
could be as simple as a bootstrap API/configuration mechanism to choose
between multiple available implementations in the current class-loader,
much like JPA and Bean Validation (and to some degree JSF/JAX-RS) allows.

Please, no.

Allow CDI to be a locked and bolted in fixed part of the server.

EE app server vendors are already wasting lots of time on implementation
pluggability that they could be spending on more meaningful platform
improvement. Despite this, pluggability still often doesn't work right
because few of the SPIs are complete enough. Breakage is common.

Unless a full module system and insanely detailed SPIs for component
interaction is specified, pluggability will always be incomplete and
unreliable. Sometimes it's important anyway (eg: JPA) but do we *really*
need pluggable CDI implementations? What does that gain the end
user/developer in real-world terms?

Adding more pluggability is not the answer. In my view, clearly specifying
what is and isn't pluggable is. JPA impl, JSF impl? must be
interchangeable. CDI, EJB3, JTA, JCA? Bolted in. You don't like 'em, roll
your own assembly of parts from a servlet container or use another EE app

Right now we have this horrible in-between mush where everything is
expected to be pluggable in theory but little is in practice. Where
components are replaced it often only works with reduced functionality and
extra bugs. It's not clear to users and developers which components can be
replaced and how. EE app server vendors don't care much because it's WAY
too hard to test and verify; they want to get their main product working
well instead. Witness JBoss AS 7, which is great using Hibernate 4 and
RESTEasy, but good luck using it with EclipseLink and Jersey - it's
possible, but not just a matter of bundling some jars.

Please leave pluggability until there's a solid module system. Either adopt
Jboss Modules from AS7 for EE7 (please!) or recognise that without a strong
module system - and lots and lots of work on improving SPIs - pluggability
of core components will not work well.

Witness for example the "fun" involved in plugging EclipseLink into JBoss
AS 7 with full dynamic weaving, JTA, etc:

Do you really want to make developing an app server into a huge
combinatorial problem - with a severe lack of spec-wide integration tests
to use for verification? Is replacing CDI solving a real developer problem
and furthering the platform, or is it just pluggability-as-a-philosophy?
Are there better places (like legacy cleanup and polishing oversights out
of EE6) that time can be spent?

Craig Ringer