The localization infrastructure basically assumes that everything shares a single global classloader. This, of course, isn't true for Eclipse, Java WebStart, and any number of other environments. ArgoUML modules also use chained classloaders to provide isolation among add-in modules in a way similar to, but slightly different, from Eclipse.
Typically in this cases the classloaders form a hierarchy with module classloader at the lowest level, the main ArgoUML module(s) class loader(s) higher up and then some type of root classloader at the top of the hierarchy. The default class loader may or may not be part of this hierarchy. What the translator class is trying to do is effectively an up-level reference reaching into the namespace of the caller which goes against the way the dependency graph flows. The Translator.addClassLoader is a hack to work around this backwardness. The class loader you need to pass is the one which knows how to load your local On Sun, Jan 30, 2011 at 6:56 PM, Mark Fortner <[email protected]> wrote: > Based on Linus' earlier message about classloaders, I used the > Translator.addClassLoader method and tried passing it > "this.getClass().getClassLoader()", and > "Thread.currentThread().getContextClassLoader()", neither of which seemed to > make any difference. You don't say what context you're doing this from. If "this" is an instance of a class loaded by your modules classloader, I would expect it to work. Using a thread-based default classloader I would expect to either not work at all or be unreliable as you moved from one environment to another. (Don't forget that your solution needs to work in all through execution environments - standalone, Java Web Start, and Eclipse). Tom ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2701696 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
