You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Brent Moore (JIRA)" <ji...@apache.org> on 2008/04/01 22:40:28 UTC
[jira] Created: (CXF-1497) Supplied WSDL soap:address not being
updated with actual host name when queried.
Supplied WSDL soap:address not being updated with actual host name when queried.
--------------------------------------------------------------------------------
Key: CXF-1497
URL: https://issues.apache.org/jira/browse/CXF-1497
Project: CXF
Issue Type: Test
Reporter: Brent Moore
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1497) Supplied WSDL soap:address not being
updated with actual host name when queried.
Posted by "Brent Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585378#action_12585378 ]
Brent Moore commented on CXF-1497:
----------------------------------
After comparison on Metro and CXF, using Glen's ReallySlowAdder as an example, I finally found that if the portName attribute is left off the @WebService annotation, or the value of portName is incorrect, the soap:address will not be filled in correctly. Metro does not have this problem, but I'm not familiar enough with the specs to say whether it is a bug or just a "feature" of Metro.
Thanks for the help and all you do,
Brent
> Supplied WSDL soap:address not being updated with actual host name when queried.
> --------------------------------------------------------------------------------
>
> Key: CXF-1497
> URL: https://issues.apache.org/jira/browse/CXF-1497
> Project: CXF
> Issue Type: Test
> Reporter: Brent Moore
> Attachments: echo-ws.war.zip, echo-ws.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1497) Supplied WSDL soap:address not being
updated with actual host name when queried.
Posted by "Brent Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584725#action_12584725 ]
Brent Moore commented on CXF-1497:
----------------------------------
Glen,
Thanks for the information. I'm still not getting this to work after working through the information above (to the best of my understanding). Here are some specific comments/results to the issues you have raised:
1) Added "/services/*" as the context path for the servlet. No difference in the result.
2) a. We are not using a file named cxf-servlet.xml - it is named servletContext.xml in the classes directory so the Spring contextloaderlistener will pick it up along with a series of spring context fragments embedded in our manager jars. We are taking advantage of the contextloader's classpath wildcard feature to do this. But in looking at the cxf documentation [3] this should not be a problem.
b. url-pattern is not a valid attribute on a jaxws:endpoint element. The reference on the note #4 at [1] looks more like a metro configuration file than a cxf one - see [4] for the docs I used in creating servletContext.xml.
3) a. Changed the wsdlLocation to "WEB-INF/wsdl/EchoService.wsdl" - no difference. Also removed the annotation attribute wsdlLocation in the implementation class - no difference. Of course, removing both will give me the generated wsdl with the correct location.
b. wsdl= is not valid in the CXF context file - see [4]. I did try it just for kicks but the app would not deploy.
After doing the above I switched back to a cxf-servlet.xml file using an example from [5]. No change. I had to use the following bean definition for the service to deploy:
<jaxws:endpoint
id="EchoService"
implementor="edu.byu.ws.echo.impl.EchoServiceImpl"
address="/EchoService"
wsdlLocation="../wsdl/EchoService.wsdl" >
</jaxws:endpoint>
With a wsdlLocation of "WEB-INF/wsdl/EchoService.wsdl" the service would not deploy - it was looking in a non-existent directory in the file system for the wsdl. I also tried an address with the host name in it (see example in [3]) but that returns the "no service was found" message on wsdl query.
I am not sure where to go next. I am attaching the maven project that built the war.
[3] http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html
[4] http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html
[5] http://cwiki.apache.org/CXF20DOC/configuration.html
Thanks for your help.
Brent
> Supplied WSDL soap:address not being updated with actual host name when queried.
> --------------------------------------------------------------------------------
>
> Key: CXF-1497
> URL: https://issues.apache.org/jira/browse/CXF-1497
> Project: CXF
> Issue Type: Test
> Reporter: Brent Moore
> Attachments: echo-ws.war.zip, echo-ws.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CXF-1497) Supplied WSDL soap:address
not being updated with actual host name when queried.
Posted by "Brent Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584725#action_12584725 ]
bdm edited comment on CXF-1497 at 4/2/08 12:04 PM:
-----------------------------------------------------------
Glen,
Thanks for the information. I'm still not getting this to work after working through the information above (to the best of my understanding). Here are some specific comments/results to the issues you have raised:
1) Added "/services/*" as the context path for the servlet. No difference in the result.
2) a. We are not using a file named cxf-servlet.xml - it is named servletContext.xml in the classes directory so the Spring contextloaderlistener will pick it up along with a series of spring context fragments embedded in our manager jars. We are taking advantage of the contextloader's classpath wildcard feature to do this. But in looking at the cxf documentation [3] this should not be a problem.
b. url-pattern is not a valid attribute on a jaxws:endpoint element. The reference on the note #4 at [1] looks more like a metro configuration file than a cxf one - see [4] for the docs I used in creating servletContext.xml.
3) a. Changed the wsdlLocation to "WEB-INF/wsdl/EchoService.wsdl" - no difference. Also removed the annotation attribute wsdlLocation in the implementation class - no difference. Of course, removing both will give me the generated wsdl with the correct location.
b. wsdl= is not valid in the CXF context file - see [4]. I did try it just for kicks but the app would not deploy.
After doing the above I switched back to a cxf-servlet.xml file using an example from [5]. No change. I had to use the following bean definition for the service to deploy:
<jaxws:endpoint
id="EchoService"
implementor="edu.byu.ws.echo.impl.EchoServiceImpl"
address="/EchoService"
wsdlLocation="../wsdl/EchoService.wsdl" >
</jaxws:endpoint>
With a wsdlLocation of "WEB-INF/wsdl/EchoService.wsdl" the service would not deploy - it was looking in a non-existent directory in the file system for the wsdl. I also tried an address with the host name in it (see example in [4]) but that returns the "no service was found" message on wsdl query.
I am not sure where to go next. I am attaching the maven project that built the war.
[3] http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html
[4] http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html
[5] http://cwiki.apache.org/CXF20DOC/configuration.html
Thanks for your help.
Brent
was (Author: bdm):
Glen,
Thanks for the information. I'm still not getting this to work after working through the information above (to the best of my understanding). Here are some specific comments/results to the issues you have raised:
1) Added "/services/*" as the context path for the servlet. No difference in the result.
2) a. We are not using a file named cxf-servlet.xml - it is named servletContext.xml in the classes directory so the Spring contextloaderlistener will pick it up along with a series of spring context fragments embedded in our manager jars. We are taking advantage of the contextloader's classpath wildcard feature to do this. But in looking at the cxf documentation [3] this should not be a problem.
b. url-pattern is not a valid attribute on a jaxws:endpoint element. The reference on the note #4 at [1] looks more like a metro configuration file than a cxf one - see [4] for the docs I used in creating servletContext.xml.
3) a. Changed the wsdlLocation to "WEB-INF/wsdl/EchoService.wsdl" - no difference. Also removed the annotation attribute wsdlLocation in the implementation class - no difference. Of course, removing both will give me the generated wsdl with the correct location.
b. wsdl= is not valid in the CXF context file - see [4]. I did try it just for kicks but the app would not deploy.
After doing the above I switched back to a cxf-servlet.xml file using an example from [5]. No change. I had to use the following bean definition for the service to deploy:
<jaxws:endpoint
id="EchoService"
implementor="edu.byu.ws.echo.impl.EchoServiceImpl"
address="/EchoService"
wsdlLocation="../wsdl/EchoService.wsdl" >
</jaxws:endpoint>
With a wsdlLocation of "WEB-INF/wsdl/EchoService.wsdl" the service would not deploy - it was looking in a non-existent directory in the file system for the wsdl. I also tried an address with the host name in it (see example in [3]) but that returns the "no service was found" message on wsdl query.
I am not sure where to go next. I am attaching the maven project that built the war.
[3] http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html
[4] http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html
[5] http://cwiki.apache.org/CXF20DOC/configuration.html
Thanks for your help.
Brent
> Supplied WSDL soap:address not being updated with actual host name when queried.
> --------------------------------------------------------------------------------
>
> Key: CXF-1497
> URL: https://issues.apache.org/jira/browse/CXF-1497
> Project: CXF
> Issue Type: Test
> Reporter: Brent Moore
> Attachments: echo-ws.war.zip, echo-ws.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1497) Supplied WSDL soap:address not being
updated with actual host name when queried.
Posted by "Brent Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brent Moore updated CXF-1497:
-----------------------------
Attachment: echo-ws.war.zip
WSDL first development in the attached war does not change soap:address value to match the deployment location of the service.
> Supplied WSDL soap:address not being updated with actual host name when queried.
> --------------------------------------------------------------------------------
>
> Key: CXF-1497
> URL: https://issues.apache.org/jira/browse/CXF-1497
> Project: CXF
> Issue Type: Test
> Reporter: Brent Moore
> Attachments: echo-ws.war.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1497) Supplied WSDL soap:address not being
updated with actual host name when queried.
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584372#action_12584372 ]
Glen Mazza commented on CXF-1497:
---------------------------------
OK, Brent, I tried to duplicate your issue with my ReallySlowAdder web service sample[1]. Good news-- I *wasn't* able to duplicate your problem with either CXF or Metro. In the pre-WAR wsdl directory I placed both a dummy soap:address of "sdkljfh" and another of an empty string, and in both cases, calling the WSDL URL (http://localhost:8080/ReallySlowAdder/services/ReallySlowAdder?wsdl) from the browser gave the correct soap:address.
Please note, if you are trying to view the WSDL by using a file system viewer from within Tomcat (such as from Windows explorer), you will *not* see the translation. The WSDL file does *not* change when viewed from the file system--it is only when you access it from the browser using an http:// request will you see the address updated.
As for your Echo sample, I was able to duplicate your problem but noticed some issues, any of which might be the problem:
1.) Following my note #4 here[2], you are not providing a "C" in your web.xml--you tie it just to * while I am using "/services/*" (see Step #7 of [2]). The CXF link given at the bottom of note #4 seems to indicate a "C" is needed.
2.) You are not using a cxf-servlet.xml file (see Step #8 of [2], "cxf-servlet.xml")--that is used for "D", however your alternative instantiation method of relying on org.springframework.web.context.ContextLoaderListener in your web.xml should be OK anyway, but you are *not* defining an apparently necessary url-pattern in your application context (see Step #8 of [2], "sun-jaxws.xml", and the cxf link given at the bottom of note #4 at [1])
3.) The way you are declaring your wsdl in your servicecontext.xml seems suspect--this is what I see:
<jaxws:endpoint id="EchoService" implementor="#EchoServiceImpl"
address="/EchoService" wsdlLocation="../wsdl/EchoService.wsdl">
</jaxws:endpoint>
I'm unsure, but wsdlLocation may mean "hardcoded WSDL, don't change the soap:address", but anyway Step #8 of [2], "sun-jaxws.xml", and the cxf link given at the bottom of note #4 at [1] seems to indicate -->wsdl="WEB-INF/<--...." should be used instead. I changed this, and it still wouldn't work. I think the biggest problem may be that you're missing the url-pattern in your jaxws:endpoint, but am unsure.
Long story short: Give yourself a "C" value for (1), provide a url-pattern for (2), and (3) switch to wsdl="WEB-INF..." instead of wsdlLocation="../wsdl..."
If that still doesn't work revert to a cxf-servlet.xml file as in my example([1] or [2]) and remove ContextLoaderListener from your web.xml. If the last part works, then we have a CXF bug, because configuration via ContextLoaderListener in addition to cxf-servlet.xml does need to work.
HTH,
Glen
[1] http://www.jroller.com/gmazza/date/20080308
[2] http://www.jroller.com/gmazza/date/20071019#notes
> Supplied WSDL soap:address not being updated with actual host name when queried.
> --------------------------------------------------------------------------------
>
> Key: CXF-1497
> URL: https://issues.apache.org/jira/browse/CXF-1497
> Project: CXF
> Issue Type: Test
> Reporter: Brent Moore
> Attachments: echo-ws.war.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1497) Supplied WSDL soap:address not being
updated with actual host name when queried.
Posted by "Brent Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585537#action_12585537 ]
Brent Moore commented on CXF-1497:
----------------------------------
The strange part is that the web service works with no problem even though the portName is missing. The real one I fixed last night is in full test mode right now. That is what brought about the initial question about best practices for dev/test/prod deployments.
Brent
> Supplied WSDL soap:address not being updated with actual host name when queried.
> --------------------------------------------------------------------------------
>
> Key: CXF-1497
> URL: https://issues.apache.org/jira/browse/CXF-1497
> Project: CXF
> Issue Type: Test
> Reporter: Brent Moore
> Attachments: echo-ws.war.zip, echo-ws.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1497) Supplied WSDL soap:address not being
updated with actual host name when queried.
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585389#action_12585389 ]
Glen Mazza commented on CXF-1497:
---------------------------------
That's great--I was grasping at straws at what the problem might be. It could be that the method for calculating soap address is different between Metro and CXF, which is why the former was OK. I'm not sure, but I think that if the portName attribute is missing or incorrect, the web service won't work properly anyway.
(Hmmm....if--and only if--the web service won't work anyway if the portName attribute is missing, perhaps we should have CXF rewrite the URL in the WSDL to "Error!!!! PortName attribute is missing!!!" Might as well point people to the problem...)
> Supplied WSDL soap:address not being updated with actual host name when queried.
> --------------------------------------------------------------------------------
>
> Key: CXF-1497
> URL: https://issues.apache.org/jira/browse/CXF-1497
> Project: CXF
> Issue Type: Test
> Reporter: Brent Moore
> Attachments: echo-ws.war.zip, echo-ws.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1497) Supplied WSDL soap:address not being
updated with actual host name when queried.
Posted by "Brent Moore (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brent Moore updated CXF-1497:
-----------------------------
Attachment: echo-ws.zip
> Supplied WSDL soap:address not being updated with actual host name when queried.
> --------------------------------------------------------------------------------
>
> Key: CXF-1497
> URL: https://issues.apache.org/jira/browse/CXF-1497
> Project: CXF
> Issue Type: Test
> Reporter: Brent Moore
> Attachments: echo-ws.war.zip, echo-ws.zip
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.