Community
Participate
Working Groups
Orbit contains two different versions of the javax.xml.soap bundle: 1.2.0 and 1.3.0. Both bundles are different: 1.2.0 has the saaj.jar as lib, 1.3.0 has the jar file expanded. When WTP now tries to deploy the saaj.jar file, it looks only for the bundle ID and the JAR file inside. This results in an error when both javax.xml.soap bundles are installed, because the lookup by bundle ID refers to the 1.3.0 version of javax.xml.soap, which hasn't the JAR file as JAR file inside. Unfortunately I cannot avoid having both versions installed because of other features having strict dependencies on both versions. The solution would be: - re-package javax.xml.soap 1.3.0 to also include the saaj.jar file - fix the vague lookup of the javax.xml.soap bundle in CopyAxisJarCommand, so that it finds the JAR in the 1.2.0 version of the bundle.
addind David and Oliver to this as they are the maintainers for the mentioned orbit bundles.
(In reply to comment #0) > - fix the vague lookup of the javax.xml.soap bundle in CopyAxisJarCommand, so > that it finds the JAR in the 1.2.0 version of the bundle. This would be my recommendation. This "vague lookup" has caused a lot of problems before, such as bug 309040 and bug bug 327009 and the "right" (well, best) way to put things into Orbit is with exploded jars, as .class files. Remember, a bundle can be used as a jar, so ... I suggest a solution be sought that uses the bundle itself.
Hi Martin, Do you have time to look at this bug and provide a patch?
Not at the moment, but I can try to come up with a patch as soon as I find the time to work on this. Ok?
So I looked at this in a bit more depth and I have a few follow-up questions: - it is indeed ok to just grab one of the available soap libs and copy that JAR file? I could change the implementation so that the CopyAxisJarCommand is able to copy the bundle JAR file instead of an embedded saar.jar, if that doesn't exist. But I wonder if it is actually important which version of the saar lib to use. Is it or not? - there is a mechanism used to delete old files from previous WTP versions that is using a hard-coded file size. Any idea how to adapt this? If I keep it the way it is, it would delete the deployed JAR file (in the case of the bundle JAR) over and over again, because the hard-coded file size is set to the value of the embedded saar.jar file. Any idea?
Oh, one more: - are there any unit test cases that I can use to verify that I don't break anything?
Hi Martin, Thanks for looking into it. 1. Looks like 1.3 added support for SOAP 1.2. We should keep it at 1.2 since Apache Axis is Soap 1.1 so there will be no benefit from SAAJ 1.3 2. I think this current delete jars mechanism is also vague. So, if we fix it for 3.4, you want to apply a similar patch to an earlier release? 3. Unfortunately, there is no specific automated test for this CopyAxisJarCommand.
Ok, that sounds to me like the first step for fixing this is to make sure the copy action looks up the saar.jar file from the javax.xml.soap bundle in version 1.2.0 (and not just from some version that is installed). The second part is to make the copy command more robust so that it can deal with exploded jars, jus in case the version 1.2.0 of javax.xml.soap is installed in exploded format. But I don't know whether this Orbit version of javax.xml.soap_1.2.0 will ever change its packaging, so maybe fixing this part is not that important at the moment. What do you think?
(In reply to comment #8) > Ok, that sounds to me like the first step for fixing this is to make sure the > copy action looks up the saar.jar file from the javax.xml.soap bundle in > version 1.2.0 (and not just from some version that is installed). > > The second part is to make the copy command more robust so that it can deal > with exploded jars, jus in case the version 1.2.0 of javax.xml.soap is > installed in exploded format. But I don't know whether this Orbit version of > javax.xml.soap_1.2.0 will ever change its packaging, so maybe fixing this part > is not that important at the moment. > > What do you think? Hi Martin, yes, I agree, I don't think that is important right now, since the 1.2 version is not exploded...and we're not going to use 1.3 which is jarred.
Hi Martin, how is this coming along? You have an estimate as to when it can be committed?
Hi Martin, do you plan on getting this fixed for M7?
what is the timeframe for M7 for webtools?
4/5 - I build declare(Start of M7) M7 05/04 (for delivery to Juno+2 on 05/09)(after this build, begin PMC +1) I suggest aiming for early part of M7, so that there's enough time to test and react to changes.
Created attachment 212906 [details] patch for version-specific bundle lookup The attached patch adds version-specific lookup for the bundle that provides the saar.jar file. I just changed the lookup for exactly this, but if you wanna adopt this for other file lookups in this Axis file copy command, it should be relatively straight forward now. Hope this helps, Martin
Please give this a good test run before committing to the project, since I wasn't able to setup a full environment for testing for this. I used a somewhat reduced setting and implemented and tested this in isolation, but having two different versions of javax.xml.soap installed. So please test this carefully in the webservice tooling environment.
Thanks Martin.
No problem, my pleasure to help and contribute here... :-) Hope testing goes well...
Hi Martin, Although we are still picking up the same SOAP 1.2 jar since at least 3.2.5, (1.2.0.v201005080501), I think we should support [1.2, 1.3). Do you know of a way to find a specific version of the plugin, and then get the install location of it?
Hey Keith, if you take a look at the patch that I submitted, there is the code implemented to lookup a specific version of the bundle. You basically need to iterate over the returned list of bundles and compare the version information yourself. I did it the lazy way, using the already implemented compareTo method, but that is working only if you have the exact version (including v201005080501). Aside of that I am not sure whether we should blindly support all versions between 1.2 and 1.3, because the implementation as it is still works only if the saar.jar lib is contained in the bundle as a JAR file. And since I don't know if other 1.2.0 versions of the bundle will follow this path, I put in the specific version information (because I know that that version looks that way). But feel free to change my patch to work with all the 1.2.x.y versions of the bundle or let me know if I should do that. Cheers, -Martin
Created attachment 213895 [details] Revised Hi Martin, maybe something like this patch? Give this a spin.
Looks good to me
Created attachment 214202 [details] Patch with updated copyrights
Released to 3.4 Tested with AllWSJUnitTests.
Thanks for improving my original patch a bit and for committing this patch. Great to have this solved for the upcoming WTP versions. I guess this is therefore part of the Juno release, right?
