Millies, Sebastian wrote:
-----Original Message-----
From: Simon Nash [mailto:[email protected]]
Sent: Thursday, November 29, 2012 7:25 AM
To: [email protected]
Subject: Re: Get Contribution at runtime?
Millies, Sebastian wrote:
-----Ursprüngliche Nachricht-----
Von: Simon Nash [mailto:[email protected]]
Gesendet: Mittwoch, 28. November 2012 19:43
An: [email protected]
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
