Community
Participate
Working Groups
To reproduce: 1. Create a new dynamic web project. Use the web services wizard to create an Axis web service in that project. 2. Notice that Apache axis jars have been copied into the web-inf/lib folder. Note the timestamp on these jar files. 3. Create a new Axis web service into the same project 4. Note that the timestamp on these jars has changed. Since the jars are already present in the web project, copying them again is not necessary.
If I recall, that logic was based on some heuristic using the file size or time stamp of axis jar (or something like that). I vaguely recall thinking we could/should version that jar using normal versioning rules ... and then it'd be exact. But ... all pretty vague, from years ago. Not sure if feasible to improve it now, or just tweak current heuristic?
(In reply to comment #1) You recall correctly David. The scenario here is that our web services wizard copies some Axis Jars into the user's Dynamic Web Project web-inf/lib folder. We used to not overwrite these jar files if a file with the same name already existed in the project. The problem with this was different versions of Axis used the same file name. (axis.jar). So if a user had a web project containing an old version of axis and went through our wizard we would not overwrite the axis jar, and the web service would not work. The best way I could think to check if we should overwrite the jar (without reading the file) was to check the file size. This heuristic works pretty well, until the size of the axis jars bundled with WTP change. This was done back in bug 155439. These are the jars we copy. (Plugin we copy them from is in brackets) axis.jar (org.apache.axis) commons-discovery-0.2.jar (org.apache.commons.discovery) jaxrpc.jar (javax.xml.rpc) saaj.jar (javax.xml.soap) wsdl4j.jar (javax.wsdl) commons-logging.jar (org.apache.commons.logging) Is there an easy (and fast) way to get the version of a jar file that exists in the users workspace? I think the easiest fix is to just update the jar sizes used in our old heuristic.
(In reply to comment #2) > (In reply to comment #1) > > > Is there an easy (and fast) way to get the version of a jar file that exists in > the users workspace? > No, not that I can think of. But it wouldn't be that hard to get the manifest.mf file from the jar, and do some simple parsing and "compares" to the manifest from the "standard" jar. But ... probably a full day of work. > I think the easiest fix is to just update the jar sizes used in our old > heuristic. You are probably right ... might be a good case to have some JUnit's for, so if/when the jars change sizes (in future) you'd at least get some indication the code had to be fixed (again).
Created attachment 164850 [details] patch to update jar sizes
Thanks Mark. Fix released.
Verified.
