On Thu, Nov 29, 2012 at 8:40 AM, ant elder <[email protected]> wrote:
> > > On Thu, Nov 29, 2012 at 6:24 AM, Simon Nash <[email protected]> wrote: > >> 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? >>>> >>>> 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
