Hello Crimsons factory finder (javax.xml.transform.FactoryFinder) uses the current threads context class loader to load extensions, instead of the class loader that loaded the FactoryFinder class (does so only if JRE is prior 1.2). I don't know the reasoning behind this, but it would be nice if the factory finders ClassLoader could be tried in case the context ClassLoader failed before giving up finding a resource alltogether. The reason for that is when an application starts using additional class loaders and threads, it can become difficult to assert that each thread that potentially accesses the Crimson package has the correct context class loader associated. The application could however make sure that the three jars of Crimson are loaded through the same ClassLoader instance. Thanks, Christian.
The context ClassLoader is checked first so the code will run correctly in the case that it is bundled as part of J2SE, which it is in JDK 1.4. In any case, if the context ClassLoader is not set, ie. it is null, then the code does try to use the current ClassLoader. Does this not work for you?
First, I need to correct myself: I actually meant javax.xml.parsers.FactoryFinder (as contained in crimson-1.1.3-src.zip) instead of javax.xml.transform.FactoryFinder (xalan-j_2_3_1-src.zip), but when looking at the sources, both take the same approach in this respect (also true for what's released with JDK1.4). > The context ClassLoader is checked first so the code will run > correctly in the case that it is bundled as part of J2SE, > which it is in JDK 1.4. In any case, if the context > ClassLoader is not set, ie. it is null, then the code does > try to use the current ClassLoader. Does this not work for > you? By default, a threads context ClassLoader is non-null (see java.lang.Thread.getContextClassLoader()) -- that means for JRE >= 1.2, setContextClassLoader() has to be called in the situation that I described, which is a little bit unhandy and unnecessary. Both FactoryFinder implementations use Class.forName() in case the context ClassLoader is null, which is fine as it is equivalent to using the calling classes ClassLoader. So I want to reformulate my suggestion to: In the newInstance() implementation, try Class.forName() in case that the context ClassLoader couldn't load it before giving up, like it is done in case the context ClassLoader is null. Thanks, Christian.
Could you explain the problem you are having w/ the code as it exists now? I would like to avoid new bugs in the code so I would like to know more about your application and the problems you are having. It might be easier to contact me directly via email at "edwingo-nospam@apache.org" but remove the "-nospam" suffix. I just happen to be updating the code to fix some other security related bugs and am also fixing other bugs as well. I am in the PDT timezone so that might be a problem w/ real time info exchange.