This is more of an FYI than a request for assistance.  But this caused
me a lot of grief and I wanted to post the issue here in case anyone
else has the same problem.  Also, I am not sure who to report this bug
to (webstart folks, xml folks, apache ...)

First, the setup:

if (factory == null) {
        Class c = Class.forName("dsi.ext.overlay.client.OverlayParser");
        Object o = c.newInstance();
        factory = new
SAXSVGDocumentFactory("dsi.ext.overlay.client.OverlayParser");
}
....
public void run() {
        document = factory.createSVGDocument(uri); 
}
This throws the ClassNotFoundException for the OverlayParser.  The same
OverlayParser that was just loaded and created.

Here is the OverlayParser declaration: 
public class OverlayParser extends SAXParser implements XMLReader

The tricky bit is that we are distributing our app with Webstart.  The
error was really spuratic though.  We would try it, and it would fail,
we would do something as trivial as turning on the webstart console, and
it might work.  Then it would fail again,...  

Even worse, it would sometimes fail within the same VM instance.  We
have a client server app, and we would logout and log back in and it
would fail when it was working before.

What was happening was that Webstart uses needs its own ClassLoader to
do its thing.  The parser factory stuff uses a class called NewInstance
to create the parsers (org.xml.sax.helpers.NewInstance.java).  My class
that contained the code to create the factory (above) was loaded by the
webstart class loader.  Therefore Class.forName uses this ClassLoader.
NewInstance would use the system class loader.  So even loading and
creating the OverlayParser class in my init() method was not enough.

NewInstance gets the ClassLoader by
static class ClassLoaderFinderConcrete extends ClassLoaderFinder {
        ClassLoader getContextClassLoader() {
                return Thread.currentThread().getContextClassLoader();
        }
}

Since the Thread class is a system class, it can be (or, perhaps, must
be) loaded by the System ClassLoader.  So when I created a thread to
load the document, the getContextClassLoader call returned the system
class loader, which had no clue where my OverlayParser was.  Again, I
have no idea why this error occurred spuratically.

The solution was to get the class loader when I created by factory and
then call setContextClassLoader with this class loader after I created
my thread that loaded the document.

This does not seem like something people should have to know about, but
I have no idea what to do with this information or who to write about
the bug.  (But the Batik users group is filled with smart people, so I
will try here first :)

Mark

---------------------
"Nonviolence is the answer to the crucial political and moral questions
of our time; the need for man to overcome oppression and violence
without resorting to oppression and violence. "
-- Martin Luther King Jr.

Mark Claassen
Donnell Systems, Inc.
300 S. St. Louis Blvd. Ste. 203 
South Bend, IN 46617
E-mail: mailto:[EMAIL PROTECTED]
Voice: (574)232-3784
Fax: (574)232-4014


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to