1

I inherited a codebase, a chunk of which is a webservice built using the Eclipse generators. The generated code appears to have numerous file paths (for wsdls, etc) which refer to locations on the original developer's box. For example, in a service class's static constructor:

url = new URL(baseUrl, "file:/C:/Users/OldDeveloperName/workspace/ServiceProject/WebContent/WEB-INF/edmo/AXIS-1-4/MainEntityService-1.0.wsdl");

Seems like a bad thing, to my naive eyes. Is this a) OK, or b) fixable? I know I could just edit it now, but there's quite a few service files and it seems like there'd be an easy correction if it's a common problem. I mean, as-is it doesn't even look deployable to me.

Paul
  • 35,689
  • 11
  • 93
  • 122
  • Usually WSDLs are needed at the build time to generate client (or server) stubs. You do not need it at runtime unless you have some dynamic web service calls. You should be able to move it to a relative path and use it. – Bimalesh Jha Aug 23 '13 at 14:29

1 Answers1

2

Original developer obviously followed the approach to store WSDL locally, which is actually a good practice. Namely, JAX-WS client before execution needs to retrieve WSDL once more from the original location to check additional metadata etc. (it sounds weird, but that's how it works). But, what if original WSDL is not available anymore or the Web service developer updated the WSDL with e.g. new method? Your Web service call would not be executed and that is not probably what you want. Therefore, people started to store WSDL together with their client, to avoid vulnerability on WSDL availability/change.

Is this a) OK, or b) fixable?

It is not OK to store WSDL on local filesystem, and that is where the original developer made the huge mistake. WSDL should be packed together with Web service client (in same JAR) and retrieved directly from the archive. There are several ways how to retrieve WSDL locally, see this tutorial for instructions. One way or another, you will have either edit the WSDL location or completely change the old code :)

References:

Miljen Mikic
  • 14,765
  • 8
  • 58
  • 66
  • Thanks very much, that was kind of my suspicion (based on developing WS apps in other languages/frameworks) but I wanted to make sure I wasn't missing some Java standard. – Paul Aug 28 '13 at 12:33
  • I'm getting a strange issue where i get (No such file or directory). for the hardcoded WSDL. where should the WSDL reside? Isn't it just inside the WAR file? – wired00 Oct 16 '14 at 03:10
  • @wired00 You can always choose not to put WSDL within your Web service client, but it is much better to pack it together with the client. In that case - yes, it should reside somewhere inside your .jar/.war archive. By using annotations or jaxws catalog file, you can specify the exact location. It is hard to tell why are you getting "No such file or directory" without seeing the actual code and the archive content. – Miljen Mikic Oct 16 '14 at 06:59
  • @MiljenMikic Thanks for the answer after nearly a day pulling whats left of my hair our, I found that the file was indeed supposed to be located in a directly located at the root of the server, this just seems nasty, as any major upgrade of the `Java` component (deployed as a `WAR`) would be vulnerable if the `WSDL` is not also updated at the same time...? It was a nightmare to figure out as the whole time, i obviously assumed its relative to the WAR root But i learnt a lot in the process. So your saying I'm correct in assuming the WSDL *should* sit inside the `WAR`? I hate legacy projects ;) – wired00 Oct 16 '14 at 09:36
  • 1
    @wired00 Yes, it definitely needs to be inside the .war. However, you should be aware that once your .war has been deployed on the application server, it will be unpacked and put somewhere on the server's filesystem. Thus, getting an error like 'no such file or directory' means that your application cannot find WSDL on the server's filesystem. But, if everything is set correctly, your application should always look for relative, not an absolute path. Compare it with OP's situation - he had an absolute path to WSDL hard-coded inside the project which was entirely wrong. – Miljen Mikic Oct 16 '14 at 10:16
  • @MiljenMikic well actually this project is doing the identical thing, inside the project is an absolute path just like that pointing to something like `url = new URL("file:/project/etc/etc/etc/etc/etc/Service.wsdl");` – wired00 Oct 16 '14 at 10:48
  • @wired00 Unless you have some catalog file incorporated (check this answer: http://stackoverflow.com/questions/4163586/jax-ws-client-whats-the-correct-path-to-access-the-local-wsdl), that cannot work. Change it to the relative path. – Miljen Mikic Oct 16 '14 at 10:50