tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject Re: Get Contribution at runtime?
Date Thu, 29 Nov 2012 08:40:00 GMT
On Thu, Nov 29, 2012 at 6:24 AM, Simon Nash <nash@apache.org> wrote:

> 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 ContributionClassLoaderProvide**r 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.
>
>

Isn't there a third option of having the switch so this new classloader
function is not active by default, so the existing tests will continue to
work? It seems like quite a big change to have the default be changed to
work this new way so some sort of switch seems like a good idea.

   ...ant

Mime
View raw message