tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: Get Contribution at runtime?
Date Thu, 29 Nov 2012 15:54:50 GMT
Millies, Sebastian wrote:
> 
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org]
>> Sent: Thursday, November 29, 2012 7:25 AM
>> To: user@tuscany.apache.org
>> Subject: Re: Get Contribution at runtime?
>>
>> Millies, Sebastian wrote:
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Simon Nash [mailto:nash@apache.org]
>>>> Gesendet: Mittwoch, 28. November 2012 19:43
>>>> An: user@tuscany.apache.org
>>>> Betreff: Re: Get Contribution at runtime?
>>>>
> [snip]
>>> Perhaps I could just change the thread context classloader. But that sounds fishy.
>>> Does not Tuscany have an extension mechanism?   There is code in the
>>> ClassReferenceModelResolver that suggests I should be able to somehow
>>> register my own ContributionClassLoaderProvider in some ExtensionPointRegistry.
>>>
>>> Is that so? Is there an example somewhere of how to do that?
>>>
>>> -- Sebastian
>>>
>> I've been thinking some more about the failing tests.  My guess is that these tests
>> aren't following the recommended best practice of keeping contribution classes
>> separate from the system classpath.  This could mean that these classes are being
>> loaded from the system classpath and your patch is causing another copy of the same
>> class to be loaded within the contribution classloader.  This might explain why you're
>> not seeing these problems with your own code, which does (I believe) follow the
>> recommended best practice.
>>
>> Fixing all the tests to avoid this issue would be a lot of work and I don't think
it's a
>> practical option.  There are two other options:
>>
>> 1) Make the new classloader load a separate copy of a class only if it's on
>>     a list of "endorsed" replacement packages.
>>
>> 2) Bring the new classloader into play only for specific contributions that
>>     are known to follow the recommended best practice.  Your recent suggestions
>>     and questions have been about how to do this.
>>
>> Option 1) would work if a replaced "endorsed" class should be used for all
>> contributions, which probably isn't a safe assumption in general.  Perhaps the best
>> approach is for Tuscany to provide both 1) and 2), which would allow a list of
>> endorsed packages to be replaced for all contributions, and would also allow
>> individual contributions to customize the global list to fit their own needs.
>>
>> In terms of how to implement 2), it's definitely a bad idea to use the thread context
>> classloader.  The extension mechanism is a possibility, but this would be applied
>> globally rather than to specific contributions.
>> Perhaps the contribution could contain some marker (similar to the "import"
>> directive) to say which packages should be overridden for that contribution.
>>
>>    Simon
> 
> The contribution classloader is determined on the basis of the "contribution type",
> which is just a String. So perhaps the contribution type could be used as the
> marker? That is, if I can define my own contribution types.
> 
> I have read Tuscany in Action section 13.2.2 and 13.2.3 about the extension mechanism.
> I guess I'll just have to experiment with this. For example, where do I put the
> META-INF directory with the properties files that registers the classloader provider
> with the extension point, i. e. what is the search path for ServiceDiscovery?
> I'll also have to read up on the jar file spec as well.
> 
I think you can put the META-INF/services directory anywhere on the
system classpath.

   Simon

> -- Sebastian
> IDS Scheer Consulting GmbH
> Geschäftsführer/Managing Directors: Michael Rehm, Ivo Totev
> Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - Registergericht/Commercial
register: Saarbrücken HRB 19681
> http://www.ids-scheer-consulting.com
> 


Mime
View raw message