I must say these are indeed good points.
From: Craig Ringer [mailto:ringerc_at_ringerc.id.au]
Sent: Tuesday, July 24, 2012 8:07 PM
To: Reza Rahman
Cc: users_at_javaee-spec.java.net
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:
https://community.jboss.org/wiki/HowToUseEclipseLinkWithAS7
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