XFire

wsdlsoap:address location attribute not set correctly in generated WSDL

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 1.1-beta-1
  • Fix Version/s: 1.1
  • Component/s: Core
  • Labels:
    None
  • Number of attachments :
    0

Description

We're using the ObjectServiceFactory in Mule (this may be an issue in the way we construct the Service..) When we grab the generated WSDL the location attribute is missing the server port. This si definitely set on the endpoint used to access the service -

</wsdl:binding>
<wsdl:service name="mycomponent">
<wsdl:port binding="tns:mycomponentHttpBinding" name="mycomponentHttpPort">
<wsdlsoap:address location="http://localhost/services/mycomponent" />
</wsdl:port>
</wsdl:service>

Should be - http://localhost:8081/services/mycomponent"

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Rob Bork added a comment -

Ross asked me to add to this issue description. The first URL below is what was generated for my Mule-hosted service. The second URL is what it needed to be. So 1) the port was missing 2) the path was wrong...for some reason it replaced 'warehouse' with 'services' and 3) the method was ommitted.

http://localhost/services/checkInv
http://localhost:8062/warehouse/checkInv?method=canOrderBeFullfilled

As I mentioned to Ross, I'm not sure where Mule stops and XFire starts on this issue. But could you please review these three items while you're looking at this issue?

Thanks.

Show
Rob Bork added a comment - Ross asked me to add to this issue description. The first URL below is what was generated for my Mule-hosted service. The second URL is what it needed to be. So 1) the port was missing 2) the path was wrong...for some reason it replaced 'warehouse' with 'services' and 3) the method was ommitted. http://localhost/services/checkInv http://localhost:8062/warehouse/checkInv?method=canOrderBeFullfilled As I mentioned to Ross, I'm not sure where Mule stops and XFire starts on this issue. But could you please review these three items while you're looking at this issue? Thanks.
Hide
Permalink
Dan Diephouse added a comment -

I"m going to guess this is because you aren't using Servlets. The only way for us to get the hostname and port is for you to use the servlet stuff, so we can do XFireServletController.getRequest().getHostname(), etc.

http://localhost/services/SERVICENAME is what we default to if we can't get that information. See the SoapHttpTransport class in XFireServletController for an example of how to register your own http transport that provides this info.

Show
Dan Diephouse added a comment - I"m going to guess this is because you aren't using Servlets. The only way for us to get the hostname and port is for you to use the servlet stuff, so we can do XFireServletController.getRequest().getHostname(), etc. http://localhost/services/SERVICENAME is what we default to if we can't get that information. See the SoapHttpTransport class in XFireServletController for an example of how to register your own http transport that provides this info.
Hide
Permalink
Ross Mason added a comment -

Spot on Dan! I've just fixed it. painless as usual

Show
Ross Mason added a comment - Spot on Dan! I've just fixed it. painless as usual
Hide
Permalink
Ross Mason added a comment -

Fixed in Mule

Show
Ross Mason added a comment - Fixed in Mule

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.