I'm blocked, help: cannot be cast to javax.xml.parsers.SAXParserFactory

[Billy Myers]

I have followed all the steps to create the proper environment for developing a plugin. I have also completed dev of another to verify that all seems to be working as expected. Regardless of how I configure or setup my pom.xml I am unable to get my xmlrpc client to execute without receiving the following error:

[INFO] [talledLocalContainer] Caused by: java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory

Additional Information:

JIRA 5.1.4

SDK 4.0

Maven2

Eclipse Indego

m2e plugin

Any help would be greatly appreciated.

[Joe Clark]

I've got it working. The problem is that the Apache XML-RPC client library you are using has a multitude of other dependencies that it will bundle into your plugin when you compile, and they clash with libraries already shipped in JIRA.

You can see what will be included in your plugin using the atlas-mvn dependency:tree command.

For example, when I add the following dependency to my plugin's pom.xml:

<dependency>
    <groupId>org.apache.xmlrpc</groupId>
    <artifactId>xmlrpc-client</artifactId>
    <version>3.1</version>
</dependency>

the following libraries will be compiled in to my plugin:

[INFO] +- org.apache.xmlrpc:xmlrpc-client:jar:3.1:compile
[INFO] |  \- org.apache.xmlrpc:xmlrpc-common:jar:3.1:compile
[INFO] |     \- org.apache.ws.commons.util:ws-commons-util:jar:1.0.2:compile
[INFO] |        \- xml-apis:xml-apis:jar:1.3.02:compile

You can see this if you open your plugin jar file in the target directory with an archive utility and look in the META-INF/lib directory. Examining each of these files, I found the following contents in the xml-apis-1.3.02.jar:

So, adding in the XML-RPC client into the plugin has also pulled in a standalone implementation of java's SAX XML Parser. However, these classes are already provided on JIRA's classpath - so now we have duplicates! Because we use OSGi, there is no immediate problem. When the plugin gets installed, it is isolated in its own class-loader and never sees the duplicate classes that are shipped with JIRA.

The problem occurs because of the implementation of the SAX libraries in Java - they use late-binding to select the appropriate parser implementation at runtime, and this late-binding is influenced by the classloaders in-play. The boundaries between your plugin's classloader and the JIRA webapp's classloader are being crossed, ending up in this scenario where the code is trying to cast between the two different implementations of SAXParserFactory.

There can be multiple ways to solve these kinds of problems, depending on the individual circumstance - it's really one of the most annoying things about OSGi in the plugin system - the solution usually ends up being layer-upon-layer of tweaks to the runtime classpath of the plugin.

In this particular case, the solution is pretty easy - we just need to stop your plugin from including a separate implementation of SAXParserFactory, so that it relies solely on the implementation provided by JIRA.

This can be done by excluding the xml-apis jar from your dependency on the xmlrpc-client jar, like so:

<dependency>
    <groupId>org.apache.xmlrpc</groupId>
    <artifactId>xmlrpc-client</artifactId>
    <version>3.1</version>
    <exclusions>
        <exclusion>
            <artifactId>xml-apis</artifactId>
            <groupId>xml-apis</groupId>
        </exclusion>
    </exclusions>
</dependency>

If you make this change to your pom.xml and then clean + rebuild your plugin, you should find that things start magically working :-)

Let me know how you go.

[Joe Clark]

I apologise if I provided a too-detailed description of some things you're already really familiar with - I thought it might help other people who run in to this problem (it happens every now and then) :-)

[Billy Myers]

Thank you Joseph, this did the trick, it seems the only thing I was missing was the exclusion from my pom.xml It makes sense and excited to get back on track. Thanks again.

[Pablo Beltran]

I stumbled with an additional problem... if the xml-apis are excluded then my plugin does not found the required SVG classes.

In my case, I use Apache Batik to make SVG graphics on the server and those classes are bundled in the newer versions of the xml-apis.

how to use a newer version of the xml-apis from a plugin than the older version provided by JIRA?

[Lukas Maruniak]

Best explanation I've seen so far. Thank you :). For depedency management I would recommend Netbeans, which can display dependency tree in very nice way.

[tsbalaji86]

I m getting the below exception and it is a blocker for me. can you help me pl? Caused by: java.lang.ClassCastException: __redirected.__SAXParserFactory cannot be cast to javax.xml.parsers.SAXParserFactory at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at org.apache.axis2.util.XMLUtils.initSAXFactory(XMLUtils.java:120) at org.apache.axis2.util.XMLUtils.<clinit>(XMLUtils.java:85) ... 32 more

[Nic Brough -Adaptavist-]

You need to make the changes that Joseph recommended.

[tsbalaji86]

Hi Nic, I am getting some diff exception .. can you help me in detail please?

[Nic Brough -Adaptavist-]

That's because the two objects you are trying to convert between are not compatible. You need to modify your code to deal with creating one from the other.

[Billy Myers]

It is my understanding that this is caused by an underlying implementation of the same class on the server side. What I am trying to figure out is how do I play well with the servers instance.

[Pablo Beltran]

No. it is because you are using tow different class loaders.

[Tormod Haugene]

An alternative to excluding the offending package would be to explicitly import the one that we need. 

Error:

ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory

The following worked for me:

// pom.xml, inside maven-jira-plugin (or maven-amps-plugin)

<Import-Package>
    javax.xml.parsers,         <<<<< Excplicitly import the one we want to use
    *;resolution:=optional
</Import-Package>

[Mark B]

For additional info that might shed light on your particular variation of this error, check out my solution here: Variation of "Cannot be cast to javax.xml.parsers.SAXParserFactory" error

[Joe Clark]

Are you familiar with OSGi? Our plugin framework is built heavily upon this. You need to ensure that your plugin is not bundling any 3rd-party libraries that are not already provided by JIRA and exported to the plugin system.

[Billy Myers]

Joseph, I am really new to the plugin development model and even though I am familiar with OSGi, I do not understand completely whats involved in implementing it with my current plugin. I believe it s ignorance on my part and trying to understand the documentation but do not understand how to make the necessary changes to my existing plugin to get it to work. Are there any resources that could you could point me to that could provide a simple example of an xmlrpc outgoing request from within a OSGi jira plugin. Something is just not clicking and I cannot put the pieces together.

[Joe Clark]

Are you using some kind of XML-RPC client or library to make the outgoing request? If so, what is it? I'll need to play around with it a bit in order to give you a clear answer.

[Billy Myers]

I have attached the example that is failing (eListener.txt) 

Hope this helps. Thank you for the further assistance

[Billy Myers]

Looks like my link was messed up, here it is again properly formatted: (eListener.txt)