geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Geronimo specs jars in OSGi
Date Thu, 17 Apr 2008 14:11:59 GMT

On Apr 16, 2008, at 8:49 AM, David Jencks wrote:

> I'd like to see an example in action before I commit myself but so  
> far I don't see any problems with this.  I assume you have already  
> or will soon verify this doesn't cause problems with the tck :-)
>
> I wonder if a package name with "osgi" in it somewhere would be more  
> appropriate?
>
> There are some specs (jacc for instance) that use a system property  
> to figure out what to create.  I've always thought this was a less  
> than brilliant idea and wonder if we can do something similar for  
> those.  I also wonder if there is a way to generalize the osgi  
> method so it might work in some non-osgi environments.  I'm looking  
> forward to seeing what you have in mind.
>
> thanks
> david jencks
>
> On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote:
>> In the past months, I've been working on making the specs jars from  
>> Geronimo working in an OSGi environment.
>> All these jars have been published and work great :-)
>> However, lots of these spec jars define factories (stax, saaj for  
>> example) that use the META-INF/services/ discovery mechanism to  
>> find an implementation of the spec and load it.  This mechanism  
>> does not fit well in OSGi (really, it does not), mainly because  
>> usually, the classloader containing the spec jar will not contain  
>> the implementation.
>> I'd like to work on these spec jars so that they will contain an  
>> OSGi BundleActivator that would change the behavior of these  
>> factories when deployed in an OSGi environment (without changing  
>> the behavior in other case).  The idea is that the activator would  
>> scan OSGi bundles when they are started to find META-INF/services  
>> and populate a map that would be used by the factory when creating  
>> an object before using the standard mechanism.
>>
>> The only real difference compared to what we currently have would  
>> be the addition of a package named org.apache.geronimo.specs.stax  
>> (for example) that would contain the needed classes (i suppose two  
>> classes), and the modification of the factories to delegate to one  
>> of these class before using the standard behavior (the class would  
>> do nothing if not deployed in an OSGi environment).
>> Has anyone any objection with such an enhancement in the specs jar ?

-1 technical veto

These are spec jars and extending the behavior of these jars on an ad  
hoc basis is bad and possibly violates the licenses of the JSRs they  
implement.


Regards,
Alan


Mime
View raw message