Bill Gorder wrote:The bean id determines the URL where the WSDL can be retrieved.
See here:
http://static.springsource.org/spring-ws/sites/1.5/reference/html/tutorial.html#tutorial-publishing-wsdl
and here:
http://forum.springsource.org/showthread.php?33791-Getting-the-WSDL-from-a-Web-service-endpoint&p=101967#post101967
long story short try
CAUTION:
Even though it can be quite handy to create the WSDL at runtime from your XSDs, there are a couple of drawbacks to this approach. First off, though we try to keep the WSDL generation process consistent between releases, there is still the possibility that it changes (slightly). Second, the generation is a bit slow, though once generated, the WSDL is cached for later reference.
It is therefore recommended to only use <dynamic-wsdl> during the development stages of your project. Then, we recommend to use your browser to download the generated WSDL, store it in the project, and expose it with <static-wsdl>. This is the only way to be really sure that the WSDL does not change over time.
Bill Gorder wrote:Well as far as finding it on disk you wont. That is more of a developer tool. As a matter of fact they caution against using this feature in production:
CAUTION:
Even though it can be quite handy to create the WSDL at runtime from your XSDs, there are a couple of drawbacks to this approach. First off, though we try to keep the WSDL generation process consistent between releases, there is still the possibility that it changes (slightly). Second, the generation is a bit slow, though once generated, the WSDL is cached for later reference.
It is therefore recommended to only use <dynamic-wsdl> during the development stages of your project. Then, we recommend to use your browser to download the generated WSDL, store it in the project, and expose it with <static-wsdl>. This is the only way to be really sure that the WSDL does not change over time.
As for your 404 I am not familiar with the book although my suggestion would be to download SOAP UI (there is a free version which is perfectly sufficient)
http://www.soapui.org/
Point this at your published WSDL and have it generate mock requests. You can use this tool to test your service endpoints. You might find the the Spring-WS side of things is not the problem.
Mike London wrote:
Bill Gorder wrote:Well as far as finding it on disk you wont. That is more of a developer tool. As a matter of fact they caution against using this feature in production:
CAUTION:
Even though it can be quite handy to create the WSDL at runtime from your XSDs, there are a couple of drawbacks to this approach. First off, though we try to keep the WSDL generation process consistent between releases, there is still the possibility that it changes (slightly). Second, the generation is a bit slow, though once generated, the WSDL is cached for later reference.
It is therefore recommended to only use <dynamic-wsdl> during the development stages of your project. Then, we recommend to use your browser to download the generated WSDL, store it in the project, and expose it with <static-wsdl>. This is the only way to be really sure that the WSDL does not change over time.
As for your 404 I am not familiar with the book although my suggestion would be to download SOAP UI (there is a free version which is perfectly sufficient)
http://www.soapui.org/
Point this at your published WSDL and have it generate mock requests. You can use this tool to test your service endpoints. You might find the the Spring-WS side of things is not the problem.
Good points all. Thanks again Bill. I'll report back with any updates.
mike
Bill Gorder wrote:I don't have time to look to hard at it at the moment but at a glance something looks off about your component scan. You should be scanning any packages with classes that have stereotype annontations (like @Endpoint)
What class is your HolidayServiceEndpoint in? If it is in com.sample.endpoint then you component scan should be sure to include that i..e.
<context:component-scan base-package="com.sample.endpoint"/>
Without that class getting picked up and registered there will be no endpoints to service your request. Like I said I only had time to give it a glance this morning but try that and maybe I can take a closer look later this afternoon.
Bill Gorder wrote:Well lets continue to set the client side apart for now and use SoapUI.
I still thing that component scan is at the heart of your problems. It is very very unconventional at best to be putting class files in the src/main/resources directory or vice versa to put .xml or .properties in the src/main/java/ The second you see once in awhile but it requires modifications to your maven pom file so that when you build the WAR they actually get placed.
A simple test would be to crack open the WAR that gets built and placed in the target directory. My guess is that things are missing or just wrong in there.
There should be a package at the top of your HolidayServiceEndpoint ex. package com.mycompany.hr.ws. This is the package that should be in the component scan. All .java files should be under src/main/java or src/test/java (if they are testing classes) this is the standard for Maven projects. Likewise non .java files should be in src/main/resources or src/test/resources.
Note for web projects maven creates a webapp directory containing your WEB-INF directory. This is where you web.xml should be located. Many people will also place their Spring config xml's somewhere beneath this web-app directory although some place them in src/main/resources as well.
I have not used IntelliJ except for a handful of times but they should adhere to the standard maven conventions. Were you building this project from existing sources or did you start from scratch?
I did not see sources listed for this book but it looks like he adapted one of the official Spring-ws examples (the holiday service). The other thing you could do is run that example you will find it here:
https://github.com/SpringSource/spring-ws/tree/master/samples
The samples link above has a number of projects/examples but the one you are interested in is the tutorial project. I think you will also find this in a samples directory if you download the distribution from here:
http://www.springsource.org/spring-web-services#download
Bill Gorder wrote:You still have your com.test.ws under src/main/resources instead of src/main/java
Not sure you are still trying to get this to work but if you are open of the WAR you are bulding with a program like 7zip and see if the files in there are what you expect and in the places you expect. Typically maven will not copy the .java /.class files it finds under the /src/main/resources tree.
Consider Paul's rocket mass heater. |