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:45:06 GMT
On Thu, Nov 29, 2012 at 8:40 AM, ant elder <ant.elder@gmail.com> wrote:

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

Sorry ignore that, mixing up the two threads related to this.

   ...ant

Mime
View raw message