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
