tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Millies, Sebastian" <Sebastian.Mill...@softwareag.com>
Subject RE: Get Contribution at runtime?
Date Thu, 29 Nov 2012 11:30:52 GMT

> -----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?
> >>
> > 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
> 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.

-- 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

View raw message