History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XFIRE-481
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dan Diephouse
Reporter: Mike McAngus
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
XFire

@WebService.wsdlLocation does not resolve to files located on the application classpath

Created: 21/Jun/06 01:01 PM   Updated: 20/Jul/06 12:56 PM
Component/s: Annotations
Affects Version/s: 1.1.1
Fix Version/s: 1.2-RC

Time Tracking:
Not Specified

Environment:
Windows Professional SP2
Sun Java 1.5.0_07
Tomcat 5.5.17


 Description  « Hide
Related to JIRA XFIRE-440

I have the "@WebService.wsdlLocation=file:wsdl/MyService.wsdl".

The only place where I can put my wsdl directory is in the Tomcat home directory. I have found no other location in or out of the classpath where I can locate the wsdl directory such that my wsdl is found when I issue the ?wsdl request.

For all other locations of the wsdl directory I get a stack trace that begins:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.codehaus.xfire.spring.ServiceBean' defined in class path resource [META-INF/xfire/services.xml]: Initialization of bean failed; nested exception is org.codehaus.xfire.annotations.AnnotationException: Couldn't load wsdl from file:wsdl/MyService.wsdl. Nested exception is java.io.FileNotFoundException: wsdl\MyService.wsdl (The system cannot find the path specified)

This issue would have been much easier to diagnose if the FileNotFoundException message contained the Absolute Path of the file it being searched for, rather than the relative path found in the annotation.

I think it would be perferable if the application classpath was searched when trying to resolve the @WebService.wsdlLocation reference.

Work Around is to add the virtual host to the location, but this still requires that the application be deployed as an exploded war.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Dan Diephouse - 22/Jun/06 10:27 AM
Thanks, adding to TODO for 1.1.2

Dan Diephouse - 24/Jun/06 12:17 PM
Have you tried just "wsdl/MyService.wsdl" - take out the file:.

Dan Diephouse - 24/Jun/06 12:20 PM
One further comment - file:wsdl/Foo.wsdl is not a valid URL. It either needs to be relative (i.e. without the scheme) or be absolute with the scheme.

Mike McAngus - 26/Jun/06 10:34 AM
Thanks Dan,

If I specify wsdl/MyService.wsdl (without specifying the scheme) for the wsdlURL element of the services.xml, or for @WebService.wsdlLocation in the Implementation class then I am successful in retreiving the original WSDL from the jar file.

Now, if only I could retrieve the stylesheet from the jar, I would be completely happy with this solution. Unfortunately, specifying the stylesheet with the following does not work:
<?xml-stylesheet type="text/css" href="style/MyService.css"?>

I can reference the stylesheet if I place it off the docroot of my local webserver and reference it with an absolute URL:
<?xml-stylesheet type="text/css" href="http://localhost/service/style/MyService.css"?>
but I have not figured out a way of referencing it if it is in the deployed war file.


Mike McAngus - 26/Jun/06 11:17 AM
FWIW,

The second request to retrieve the WSDL fails with the exception information below. I will test this scenario in the new 1.1.2 release and if it still occurs then I will create a new JIRA.

---------- Begin included text ----------

2006-06-26 12:12:15,768 ERROR org.codehaus.xfire.transport.http.XFireServletController - Couldn't invoke servlet request.
org.codehaus.xfire.XFireRuntimeException: Couldn't generate WSDL.. Nested exception is java.io.IOException: Stream closed
java.io.IOException: Stream closed
at java.io.BufferedInputStream.getBufIfOpen(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at java.io.FilterInputStream.read(Unknown Source)
at org.codehaus.xfire.wsdl.ResourceWSDL.copy(ResourceWSDL.java:60)
at org.codehaus.xfire.wsdl.ResourceWSDL.write(ResourceWSDL.java:47)
at org.codehaus.xfire.DefaultXFire.generateWSDL(DefaultXFire.java:104)
at org.codehaus.xfire.transport.http.XFireServletController.generateWSDL(XFireServletController.java:317)
at org.codehaus.xfire.transport.http.XFireServletController.doService(XFireServletController.java:116)
at org.codehaus.xfire.transport.http.XFireServlet.doGet(XFireServlet.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
2006-06-26 12:12:15,778 ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/acre].[XFireServlet] - Servlet.service() for servlet XFireServlet threw exception
org.codehaus.xfire.XFireRuntimeException: Couldn't generate WSDL.. Nested exception is java.io.IOException: Stream closed
java.io.IOException: Stream closed
at java.io.BufferedInputStream.getBufIfOpen(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at java.io.FilterInputStream.read(Unknown Source)
at org.codehaus.xfire.wsdl.ResourceWSDL.copy(ResourceWSDL.java:60)
at org.codehaus.xfire.wsdl.ResourceWSDL.write(ResourceWSDL.java:47)
at org.codehaus.xfire.DefaultXFire.generateWSDL(DefaultXFire.java:104)
at org.codehaus.xfire.transport.http.XFireServletController.generateWSDL(XFireServletController.java:317)
at org.codehaus.xfire.transport.http.XFireServletController.doService(XFireServletController.java:116)
at org.codehaus.xfire.transport.http.XFireServlet.doGet(XFireServlet.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)


Christoph Sturm - 26/Jun/06 11:48 AM
setting the fix version to unknown for now

Martin Tilma - 12/Jul/06 10:21 AM
I use xfire 1.1.2. and maven. When I generate the sources form wsdl the ..Impl classes contain a wsdllocation with file:/ .... After deploying on a test server the application won't start because of the missing wsdl files.

My workaround is, replacing the wsdllocation with a relitive path:

pom.xml
<executions>
					<execution>
			          	<id>generate-sourec</id>
						<phase>generate-sources</phase>
						<configuration>
							<tasks>
								<taskdef name="wsgen" classname="org.codehaus.xfire.gen.WsGenTask"
										classpathref="maven.compile.classpath" />

								<wsgen outputDirectory="${project.build.directory}/xfire-source"
										wsdl="${basedir}/src/main/resources/wsdl/SessionService.wsdl"
										package="nl.tesis.webservices" overwrite="true" />
								<wsgen outputDirectory="${project.build.directory}/xfire-source"
										wsdl="${basedir}/src/main/resources/wsdl/ApplicationService.wsdl"
										package="nl.tesis.webservices" overwrite="true" />	
								<wsgen outputDirectory="${project.build.directory}/xfire-source"
										wsdl="${basedir}/src/main/resources/wsdl/AuditingService.wsdl"
										package="nl.tesis.webservices" overwrite="true" />
								<wsgen outputDirectory="${project.build.directory}/xfire-source"
										wsdl="${basedir}/src/main/resources/wsdl/DataService.wsdl"
										package="nl.tesis.webservices" overwrite="true" />	
								<wsgen outputDirectory="${project.build.directory}/xfire-source"
										wsdl="${basedir}/src/main/resources/wsdl/SchoolService.wsdl"
										package="nl.tesis.webservices" overwrite="true" />		
								<wsgen outputDirectory="${project.build.directory}/xfire-source"
										wsdl="${basedir}/src/main/resources/wsdl/UserGroupService.wsdl"
										package="nl.tesis.webservices" overwrite="true" />	
								<wsgen outputDirectory="${project.build.directory}/xfire-source"
										wsdl="${basedir}/src/main/resources/wsdl/ApplicationService.wsdl"
										package="nl.tesis.webservices" overwrite="true" />								
								<wsgen outputDirectory="${project.build.directory}/xfire-source"
										wsdl="${basedir}/src/main/resources/wsdl/UserService.wsdl"
										package="nl.tesis.webservices" overwrite="true" />										
							</tasks>
							<sourceRoot>${project.build.directory}/xfire-source</sourceRoot>
						</configuration>
						<goals>
							<goal>run</goal>
						</goals>
					</execution>
          <execution >
          	<id>fix-sources</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <tasks>
                <ant inheritRefs="true" antfile="${basedir}/build.xml">
                  <target name="fix-source"></target>
                </ant>
              </tasks>
            </configuration>
          </execution>					
				</executions>
build.xml
<?xml version="1.0" encoding="UTF-8"?>
<project default="fix-source">
	
	<property name="xfire-source" value="${basedir}/target/xfire-source" />
	
	<target name="fix-source">
	
		<property name="replace" value="file:${basedir}/src/main/resources/"/>
		
		<echo>fix source in: ${xfire-source}</echo>
		<echo>replace: ${replace}</echo>
		
		<replace dir="${xfire-source}" value="" token="${replace}">
		  <include name="**/*.java"/>
		</replace>

	</target>
	
</project>

It is not beautyfull but it works. What would be the right solution ?


Dan Diephouse - 12/Jul/06 10:27 AM
Looking into this... will get back to you all soon

Dan Diephouse - 20/Jul/06 12:56 PM
This is resolved in current SVN. Instead of adding the @WebService.wsdlLocation attribute we now generate a service descriptor, which should help.