As it turns out, this ended up being a class loader problem. In reviewing the James source code, I see two problems: 1) It uses this.class.getClassLoader(), rather than the preferred Thread.currentThread.getContextClassLoader(). This is not a problem right now, as the Apache James developers have control over the entire application, but could become a difficult bug to track down in the future. In addition, as soon as you start adding multiple class loaders, chaining class loaders with parents becomes impossible (see next point) because it sets the same class loader as multiple parents. In the source code, all instances of this.getClass().getClassLoader() (or whatever.getClass().getClassLoader()) should be replaced by Thread.currentThread().getContextClassLoader() 2) The greater problem is that it does not call Thread.currentThread().setContextClassLoader(classLoader). This means that any code that uses the standard method Thread.currentThread().getContextClassLoader() (as my code does) will not get the correct class loader, and thus will not be able to load the appropriate resources. In fact, I was getting the primary class loader, which only loads the Phoenix Jar. I had to add into my code the following (the class loader's parent is already set): Thread.currentThread().setContextClassLoader(MyClass.class.getClassLoader ()); By the nature of Java class loaders, it is expected that the thread's Context ClassLoader is always kept current, and that any new class loaders are added to the chain. I think that this change should be made in the Apache James source code.
I realize that this is the Users list, so if I should send this e-mail to the Developers list, let me know. Thanks, Ben On 8/31/05, Ben Lindahl <[EMAIL PROTECTED]> wrote: > > Actually, this is not resolved. It now loads classes from the classes > directory, but it does not load resources from there (this probably has > something to do with the fact that when it loads classes, it does not > actually load the classes directory onto the classpath). Therefore, I need a > way to get properties files as resources from the classpath, without putting > them in Jar files. Any ideas? > > Thanks. > > On 8/30/05, Ben Lindahl <[EMAIL PROTECTED]> wrote: > > > > It looks as though it should be using SAR-INF/classes, so perhaps the > > trouble I had was related to something else. It now does seem to be loading > > the class out of SAR-INF/classes. > > > > Thanks. > > > > On 8/30/05, Stefano Bagnara < [EMAIL PROTECTED]> wrote: > > > > > > Hi Ben, > > > > > > I've not encountered the problem, but I can give you an hint: you > > > should > > > look at org.apache.james.transport.Loader to see how James does handle > > > the > > > classloading for matcher/mailets. Maybe this helps. > > > > > > Stefano > > > > > > > Hey all, > > > > > > > > I'm trying to set up a classes directory within one of my SAR > > > > projects. I realize that SAR-INF/classes doesn't work, but I > > > > would like to have a classes directory to avoid having to > > > > modify my application's configuration files in Jar files. The > > > > only solution I have come up with is to dynamically load a > > > > class directory at runtime through the UrlClassLoader, but > > > > this doesn't seem like a clean solution. > > > > > > > > Has anyone else encountered a similar problem, and if so, how > > > > did you address it? > > > > > > > > Thanks in advance! > > > > > > > > - Ben > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >
