Hi Tom, The "this" I'm referring to is the ArgoPrintDialog. My thought is that whatever thread was responsible for launching the dialog would be responsible for loading resources as well. I'm at work right now, so I can't take a look at the code, but do you know if there's a top-level context object like an application context which has resources. The Swing Application Framework (and it's derivatives) always give you an application level handle to resources, and if we don't have a handle like this, it might be a good idea to add it.
Cheers, Mark On Mon, Jan 31, 2011 at 8:12 AM, Tom Morris <[email protected]> wrote: > 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]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2701706 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]]
