Hi Edwin,
Let me see if I can summarize where we're at here (and explain to myself
why Rob's code works for him if Edwin's right about what's going on). If
Rob's on a Sun JDK 1.4.x and doesn't use the endorsed standards override
mechanism, he should break if Edwin's right because he'll pick up Crimson's
JAXP/SAX factories before his hacked Xerces libs, and the crimson factories
will still refuse to do anything but look at the context class loader.
If he uses endorsed standards override with his hacked Xerces, then he'll
always get his hacked xerces because of the fallback he's introduced and
because the bootclassloader is the one that's loaded these "endorsed"
API's.
If the above is substantially correct, then the fallback is still useful in
that at least one implementation--provided via endorsed standards--is
accesible to an app that refuses to use the context classloader, even if
that app can never override this one.
Yikes; this is interesting stuff...
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
Edwin Goei
<[EMAIL PROTECTED] To: Rob Walker <[EMAIL
PROTECTED]>
om> cc: [EMAIL PROTECTED]
Subject: Re: SAX parser class
05/16/2002 loading
05:33 PM
Please respond
to
xerces-j-user
Rob Walker wrote:
>
> > Are you saying that you tried your proposed solution on JDK 1.4 and got
> > it to work? I don't know enough about your app to understand. I think
> > we agree that the problem exists in JDK 1.4. In addition, I think that
> > the proposed solution will probably still fail unless you are using JDK
> > 1.4 in a non-standard way.
>
> The problem (and solution) are exactly the same under JDK1.3 and JDK1.4.
> Due to the nature of OSGi, which uses modular classloaders, the
Xerces.jar is
> not on the classpath. It is loaded by a custom classloader.
>
> >
> > I would expect that setting the context CL to your custom CL which has
> > access to the impl classes will always work, however. Unfortunately, I
> > have not heard of a better solution to this problem yet.
>
> This does always work - but it means every single thread that is created
in the
> VM has to remember to set it's context classloader - which is a total
pain. In
> every case, the solution is "set context classloader from
this.class.classloader" -
> which implies to me that Xerces could have this as a fallback option if a
class is
> not found through the thread context classloader.
In JDK 1.4, the FactoryFinder (package private) class is part of rt.jar
which means that if you use the usual class loading delegation model, it
will be loaded by the bootstrap CL. Thus, the code
FactoryFinder.class.getClassLoader()
will return the bootstrap CL and not your custom CL that has access to
the parser impl that you want to load. The result is that the class
will still not be found.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
