I agree that these can all be relevant in some integrations, although
they do not all play a role in every integration. Most integrations can
be done perfectly well considering only a subset of them.
The problem you describe in the JPA API has nothing to do with the JPA
integration but is a problem in general with Java and the task of
processing annotations on a classfile as a precursor to instrumenting
the classes. There is no nice way provided in the JDK to process
annotations without loading the classes first, hence the availability in
the JPA SPI of a throwaway classloader. Most providers and frameworks
that do this kind of thing read the bytes using libraries like ASM
(without loading the classes) to avoid the first classloading stage,
however, baking a reliance on a third party library into an SPI is
generally not considered a good idea. I am not sure if this comment
serves to prove or disprove your point (you mention it in point 2.), but
I thought it worth qualifying :-)
On 25/07/2012 10:34 AM, Jason T. Greene 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
>>>
>
>