Bug 8406

Summary:	Crimsons factory finder could try more than only the context class loader
Product:	Crimson	Reporter:	Christian Schnell <Christian.D.Schnell>
Component:	other	Assignee:	Edwin Goei <edwingo>
Status:	ASSIGNED ---
Severity:	enhancement
Priority:	P3
Version:	1.1.3
Target Milestone:	---
Hardware:	Other
OS:	All

Description Christian Schnell 2002-04-23 08:45:35 UTC

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.

Comment 1 Edwin Goei 2002-04-30 22:45:01 UTC

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?

Comment 2 Christian Schnell 2002-05-01 11:48:56 UTC

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.

Comment 3 Edwin Goei 2002-05-01 18:00:29 UTC

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.