You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Thomas DeWeese <Th...@Kodak.com> on 2003/09/02 19:21:14 UTC

Re: Woes concerning the Crimson parser, Batik, Webstart, and ClassLoaders

Mark Claassen wrote:
> 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 ...)

Hi Mark,

     I don't think I can fix your problem, but I suspect the
problem is really a WebStart problem.  It sounds to me like some
sort of race condition in them setting the Thread Context on the thread
used to load your application (reading the docs for getContextClassLoader
the behaviour should be that your new thread uses your application class
loader).

     When you report it to them I would suggest bypassing the SAXSVGDocumentFactory
and try calling:
             XMLReader parser = XMLReaderFactory.createXMLReader(parserClassName);


     Anyway, good luck.

> 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:mark.claassen@donnell.com
> Voice: (574)232-3784
> Fax: (574)232-4014
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org