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