I have CXFServlet loading "WEB-INF/wsdl/hello.wsdl" just fine. not sure why it didn't work for me yesterday, possibly because I was using an absolute "/WEB-INF/wsdl/hello.wsdl" form... So things are cool.
Cheers, Sergey > > Hi > > I was about to ask a question if a wsdl document should always be located > inside WEB-INF/classes or WEB-INF/libs, and then I found this thread... > > I agree it's a pain having to relocate a resource like > WEB-INF/wsdl/hello.wsdl into WEB-INF/classes/wsdl/hello.wsdl just to make it > work, esppecially when one deal with prepackaged wars. > > Unfortunately I have little knowledge of Spring at this stage, but the idea > of using some Spring webapp-aware context classes looked promising so that > resources like "/WEB-INF/wsdl/hello.wsdl" could also be resolved. Is it > where CXFServlet can be enhanced a bit ? > > By the way, I'm using Tomcat 5.5.25, Windows XP. > > Thanks, Sergey > > > CMoesel wrote: >> >> I ran into this very same issue when trying to run the war using the >> maven jetty plugin. It also searched from the working directory instead >> of the root of the application context. It worked however, when I tried >> it in Tomcat 5.5 and Jboss 4.0 standalone. >> >> In order to get it working in the maven jetty plugin though, I had to >> put my wsdl in the classpath (WEB-INF/classes/myservice.wsdl) and then >> refer to it in the <jaxws:endpoint> as wsdlLocation="myservice.wsdl" >> (note the lack of "classpath:" prefix). >> >> If you don't mind putting it in the classpath, that may be the best >> solution for you right now (assuming it works!). >> >> -Chris >> >> -----Original Message----- >> From: Steven E. Harris [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, May 02, 2007 11:32 PM >> To: [email protected] >> Subject: Re: jaxws:endpoint wsdlLocation attribute -- form for class >> path reference? >> >> "Jiang, Ning \(Willem\)" <[EMAIL PROTECTED]> writes: >> >>> I just try the latest kit's (build with latest trunk) helloworld >>> sample with the wsdlLocation="WEB-INF/wsdl/hello_world.wsdl". >>> >>> It is workable. >> >> That's good to hear. >> >>> Can you check your wsdl in the war or try the CXF helloworld sample? >> >> Actually, I'm deploying via an explode WAR directory, but my WSDL is >> in the proper place in the directory. I just tried deploying via an >> actual WAR file as well. The files are in the directory and in the >> WAR. I tried matching your location specification above: >> "WEB-INF/wsdl/myfile.wsdl". No matter what, the search fails, >> apparently taking the current working directory as the base for the >> search: >> >> Caused by: javax.wsdl.WSDLException: WSDLException: >> faultCode=PARSER_ERROR: Problem parsing 'WEB-INF/wsdl/myfile.wsdl'.: >> java.io.FileNotFoundException: C:\Program >> Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl >> (The system cannot find the path specified) >> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source) >> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> at >> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.jav >> a:177) >> at >> org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java >> :141) >> at >> org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java: >> 81) >> ... 42 more >> Caused by: java.io.FileNotFoundException: C:\Program >> Files\Java\add-ons\apache-tomcat-6.0.10\bin\WEB-INF\wsdl\myfile.wsdl >> (The system cannot find the path specified) >> at java.io.FileInputStream.open(Native Method) >> at java.io.FileInputStream.<init>(FileInputStream.java:106) >> at java.io.FileInputStream.<init>(FileInputStream.java:66) >> at >> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.ja >> va:70) >> at >> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnec >> tion.java:161) >> at >> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEnt >> ity(XMLEntityManager.java:653) >> at >> com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocV >> ersion(XMLVersionDetector.java:186) >> at >> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML1 >> 1Configuration.java:771) >> at >> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML1 >> 1Configuration.java:737) >> at >> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.jav >> a:107) >> at >> com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.jav >> a:225) >> at >> com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Docume >> ntBuilderImpl.java:283) >> ... 48 more >> >> >> If I start Tomcat from a shell, the same error arises, but the current >> working directory matches that of the shell that called startup.sh. >> >> I'll give up for now and try again with tomorrow's snapshots. >> >> -- >> Steven E. Harris >> >> > > -- > View this message in context: > http://www.nabble.com/jaxws%3Aendpoint-wsdlLocation-attribute----form-for-class-path-reference--tf3684247.html#a12633374 > Sent from the cxf-user mailing list archive at Nabble.com. ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
