Community
Participate
Working Groups
While doing some work with Web Service testing, I discovered that the latest Atlassian JIRA plug-ins for Helios bring in version 1.3.0 of the javax.xml.soap plug-in from Orbit. This plug-in, when in the same workbench as the 1.2.0 version of the plug-in from Orbit (which comes with WTP), causes some issues. javax.xml.soap (1.2) is an old-school plug-in jar wrapper that takes saaj.jar and exposes it in Eclipse. javax.xml.soap (1.3) is a new-school OSGI-compatible wrapper that builds the individual saaj classes and wraps them to expose them in Eclipse. As Nick said in a recent IRC chat - ".jar!/org/whatever/*.class is better than .jar!foo.jar". However... in my case, it causes the lovely java.lang.VerifyError when I try to use a utility class that takes advantage of classes from javax.xml.soap. The other oddity is that 1.2 has a more recent date - 1.2.0.v201005080501 vs. 1.3.0.v200904281458. So even though 1.3 has the higher version, the date is a year old. Does anyone else have issues with this?
Sorry to let this sit so long, Brian. I've not thought through the details, but before I do ... do you have a recommend solution? I think there are some that need/use the saaj.jar "directly", but not sure.
Hey David, thanks for getting back to me. I've done everything I can think of - modifying my MANIFEST.MF to bring in the correct version a dozen ways (might be exaggerating), changing the MANIFEST.MFs of the 1.2 and 1.3 versions of the orbit plug-in (at Chris A's suggestion). Nothing has worked. You can see our discussion here: https://jira.jboss.org/browse/JBIDE-6450 I'm open to suggestions.
One of the great folks at JBoss has come up with an answer... The problem is that javax.xml.ws, javax.xml.rpc, and org.apache.axis import javax.xml.soap, but don't declare any version. This can be solved by fixing those plug-ins in Orbit, but this could affect plugins that depend on javax.xml.ws, javax.xml.rpc and/or on org.apache.axis. This can also be solved by simply not using those plug-ins and wrapping the rpc and axis jars in my own project so I get the right versions. But this isn't what I consider the best solution for the long term. You can see the whole conversation at https://jira.jboss.org/browse/JBIDE-6450
> The problem is that javax.xml.ws, javax.xml.rpc, and org.apache.axis import > javax.xml.soap, but don't declare any version. > > This can be solved by fixing those plug-ins in Orbit, but this could affect > plugins that depend on javax.xml.ws, javax.xml.rpc and/or on org.apache.axis. Are you saying for them to import/depend on version 1.3 of javax.xml.soap? If so, then I see what you mean about the potential for breaking existing clients. But ... I wonder ... I see that org.apache.axis (version 1.4 ... I assume that's what you mean) has a "require bundle" on soap, and others, such as ... javax.xml.soap;bundle-version="[1.2.0,2.0.0)" I seem to recall some vague memory that "require bundle" and "import package" do not always play well together. I wonder if changing the require bundle to import package (with a wide range, such as 1.2 to 2.0) would help? I know you are tired of experimenting with this issue ... what this type of solution one of the ones you tried? Or, does specifying a wide range on "import package" (e.g. 1.2 to 2.0) sufficient to get things loaded up correctly?
(In reply to comment #4) > I seem to recall some vague memory that "require bundle" and "import package" > do not always play well together. I wonder if changing the require bundle to > import package (with a wide range, such as 1.2 to 2.0) would help? I know you > are tired of experimenting with this issue ... what this type of solution one > of the ones you tried? > > Or, does specifying a wide range on "import package" (e.g. 1.2 to 2.0) > sufficient to get things loaded up correctly? Ok, so I tried changing the axis 1.4 MANIFEST.MF to make it an import package instead of require-bundle and it's still not seeing classes in the javax.xml.soap plug-in. I get this exception: javax.xml.ws.WebServiceException: Unknown class type javax.xml.soap.SOAPMessage at com.sun.xml.internal.ws.api.pipe.Stubs.createDispatch(Stubs.java:177) at com.sun.xml.internal.ws.client.WSServiceDelegate.createDispatch(WSServiceDelegate.java:377) at com.sun.xml.internal.ws.client.WSServiceDelegate.createDispatch(WSServiceDelegate.java:388) at com.sun.xml.internal.ws.client.WSServiceDelegate.createDispatch(WSServiceDelegate.java:370) at javax.xml.ws.Service.createDispatch(Service.java:325) at org.jboss.tools.ws.ui.utils.JAXWSTester2.doTest(JAXWSTester2.java:144)
(In reply to comment #5) > (In reply to comment #4) > > Ok, so I tried changing the axis 1.4 MANIFEST.MF to make it an import package > instead of require-bundle and it's still not seeing classes in the > javax.xml.soap plug-in. > So, was that with just import packages? Or did you also use version ranges on exports/imports? What I'm after is if we can use import packages (through out these related bundles) with a wide range such as [1.2,2.0) or are you are saying the key to get it all to work together is to have a narrower range that excludes 1.2 such as [1.3,2.0)? If this later case, I'm not sure there's much we in Orbit can do ... at least not until everyone (Keith :) moves up to javax.xml.soap 1.3. I've no idea what's changed ... but obviously something has so that its not compatible, apparently. Brian, do you have a small, tiny test case that demonstrates the problem, that you could attach to this bug? Such as a small Eclipse Application that just throws the exception? (i.e. doesn't have to do real work). I'd be easier for me to investigate myself then, instead of just asking you questions. :) Thanks,
> Brian, do you have a small, tiny test case that demonstrates the problem, that > you could attach to this bug? Such as a small Eclipse Application that just > throws the exception? (i.e. doesn't have to do real work). I'd be easier for me > to investigate myself then, instead of just asking you questions. :) I tried creating a small app that would duplicate this issue, but haven't had any luck. It seems there's some particular combination of imported plug-ins that blows things up. That said, we did hit upon one difference between the javax.xml.soap versions 1.2 and 1.3. The 1.2 plug-in has this line at the bottom of the MANIFEST.MF: Require-Bundle: system.bundle When we add the same line to the 1.3 version of the plug-in, my issues go away. This seems like a relatively low-risk fix for the Orbit plug-in.
Created attachment 183506 [details] Patch for javax.xml.soap 1.3
I agree, low risk fix.
applied patch for Indigo M4
Thanks David!
