Millies, Sebastian wrote:
-----Ursprüngliche Nachricht-----
Von: Simon Nash [mailto:n...@apache.org]
Gesendet: Mittwoch, 28. November 2012 19:43
An: user@tuscany.apache.org
Betreff: Re: Get Contribution at runtime?
Millies, Sebastian wrote:
[snip]
Of course you're right. The new classloader should look for the
external libs,
then delegate to the parent (the ContributionClassLoader). I was
still thinking
of changing the order in which classes are searched (contribution and
imports first,
parent last), but that's no problem here.
The whole idea has a drawback, however: The external libraries are
not visible to the
contributions, but the other way around. So I could not have
appropriately typed references
in my contributions, but would have to use reflection, right?
A solution might be to make the new classloader the delegation parent
of the contribution classloader, and load the external libraries before
Tuscany loads the contributions. I think this would be safe if the
contributions don't pass any references to these overriding external
external libraries to the Tuscany runtime.
[snip]
Simon
Thank you for putting it so plainly. That's exactly what I meant, too. I'm just
not clear at the moment how the Tuscany node APIs allow me to set the
classloader
for a contribution. That's what the code clutter (now snipped) in my previous
post was all about.
Thanks for clarifying this, and my apologies for misunderstanding that
part of your previous post.
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
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
