+1
On 25 July 2012 16:34, Jason T. Greene <jason.greene_at_redhat.com> wrote:
> 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 java.io.File.
> 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 <reza_rahman_at_lycos.com
>> <mailto:reza_rahman_at_lycos.com>> wrote:
>>
>>> I must say these are indeed good points…
>>>
>>> *From:*Craig Ringer [mailto:ringerc_at_ringerc.id.au
>>> <mailto:ringerc_at_ringerc.id.au>]
>>> *Sent:* Tuesday, July 24, 2012 8:07 PM
>>> *To:* Reza Rahman
>>> *Cc:* users_at_javaee-spec.java.net <mailto: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
>>>
>
>
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat