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 06:24:49 GMT
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?
>> 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.

> 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

View raw message