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

From: Jason T. Greene <>
Date: Wed, 25 Jul 2012 09:34:03 -0500

We really need a complete SPI to do integration correctly. Such an SPI
would require:

1. A proper resource abstraction - No reliance on JarURLconnection and
bad assumptions that a URL can be easily converted to
2. Annotation metadata abstraction - Containers have the ability to
optimize annotation searching without using bloated/slow classloading
and reflection.
3. Reflection metadata abstraction - Allow a container to actually cache
and share Field/Method objects
4. Resource registration mechanisms - Interoping with CDI, EE Injection
& Naming
5. Cross framework integration (mechanism to register interceptors or
access other hooks in other plugable frameworks)
6. Full lifecycle - so that containers with support suspend/resume of
deployment work, cleanup is properly done and so on.
7. Modularity, or at least some abstraction to ensure class loading is
compatible with the container (no framework provided classloaders,
reasonable usage of dependencies etc). Also no more assumptions that
framework classes and deployment classes are on the same Classloader.
8. Contracts for Thread Local usage, thread creation/pooling.

To use one example where integration goes wrong, look at the JPA
contract. Since some providers use instrumentation, the SPI attempts to
enable it, but without any of the previously listed items. The net
effect is that a container has to execute classloading *twice* for every
deployment that uses JPA. It has to load every class so it can analyze
annotations, and then throw away the Classloader so that it can create a
fresh one with instrumented versions of the classes.

On 7/25/12 8:53 AM, Jeff Genender wrote:
> 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 whole.
> Jeff
> 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
>> *Cc:* <>
>> *Subject:* Re: [javaee-spec users] [jsr342-experts] Re: Modularization
>> Framework/SPI
>> 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 server.
>> 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

Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat