Hi,
I have a query regarding class loaders and threading in openmap - in
particular if there is any difference when loading a layer at startup as
opposed to switching on a layer manually via the Layers menu or Edit
Layers panel.
I'm developing an XML plug in layer that loads images onto a map. The
project is deployed/run via Ant 1.6.2.
Since my XML layer uses JAXB to unmarshal XML files, I set the context
classloader to be the current class loader before openmap starts.
i.e. Before the OpenMapFrame gets created I do:
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoa
der()); in my client. Note that this.getClass().getClassLoader() is an
instanceof net.jini.loader.pref.PreferredClassLoader and contains the
jars required (i.e. jaxb and xml parser factories etc)
A cut down version of the XML/JAXB code is:
// Create a jaxbcontext capable of handling unmarshalling.
JAXBContext jc =
JAXBContext.newInstance("com.classforge.jswat.client.layers.tiled.bindin
g", this.getClass().getClassLoader());
// Create an unmarshaller
Unmarshaller u = jc.createUnmarshaller();
URL fileUrl = new URL(fileName);
// Unmarshall an instance document into a tree of java content
// objects composed of classes from the specified package
Object obj = u.unmarshal(fileUrl);
Now for the problem.
If I include this XML layer in the openmap.startUpLayers list I get a
ClassCastException when u.unmarshal(fileUrl) is performed, and the image
loading never occurs. However, if I run the client without the XML layer
in the startUpLayers list I select it manually via the Layers menu and
the image loading works.
The ClassCastException reported is:
[java] java.lang.ClassCastException
[java] at javax.xml.parsers.SAXParserFactory.newInstance(Unknown
Source)
[java] at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.getXMLReader(AbstractUnm
arshallerImpl.java:74)
[java] at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmars
hallerImpl.java:131)
[java] at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmars
hallerImpl.java:136)
[java] at
javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmars
hallerImpl.java:145)
[java] at
com.classforge.jswat.client.layers.tiled.XMLTiledImagePlugIn.listTiles(X
MLTiledImagePlugIn.java:433)
[java] at
com.classforge.jswat.client.layers.tiled.XMLTiledImagePlugIn.loadTiles(X
MLTiledImagePlugIn.java:168)
[java] at
com.classforge.jswat.client.layers.tiled.XMLTiledImagePlugIn.getRectangl
e(XMLTiledImagePlugIn.java:104)
[java] at
com.bbn.openmap.plugin.PlugInLayer.prepare(PlugInLayer.java:324)
[java] at
com.bbn.openmap.layer.policy.StandardRenderPolicy.prepare(StandardRender
Policy.java:67)
[java] at
com.bbn.openmap.layer.OMGraphicHandlerLayer$LayerWorker.construct(OMGrap
hicHandlerLayer.java:648)
[java] at
com.bbn.openmap.util.SwingWorker$2.run(SwingWorker.java:117)
[java] at java.lang.Thread.run(Unknown Source)
Note I have narrowed this problem down to the following:
If layer is on at startup => then when the JAXB code above is executed
the context class loader is not the same as current (and would have to
include a hack in the JAXB code above to setContextClassLoader on
current thread if not same as current). Note I have included a hack to
reset the context class loader in the JAXB code above, and verified that
this works, but it is not a very good solution.
If layer is not on at startup, can select manually, and context class
loader is same as current and JAXB code above executes ok.
Can anyone tell me if openmap treats startup layers differently wrt
threading/classloading - I thought setting the context class loader
before calling any openmap code would ensure that any threads created by
openmap would also use this context classloader?
Thanks for any insight. Anna.
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Tue May 10 2005 - 21:00:24 EDT