Hi All,
If you successfully used JAXB2 over https can you take a quick moment
and give us a little feedback on how did you managed to make it work
properly? Because of this:
I ran into the same issue = i.e. everything is correct in the generated
wsdl now with the EXCEPTION of the soap:address location : instead to
point to https as it should, it points to http.
We tried to not hack the
org.codehaus.xfire.transport.http.XFireServletTransport class to replace
the http with https ... by trying to modify the config settings in
services.xml as follows:
<createDefaultBindings>false</createDefaultBindings>
<bindings>
<soap11Binding name="e:serviceSoap11Binding"
transport="http://schemas.xmlsoap.org/soap/http";
allowUndefinedEndpoints="false">
<endpoints>
<endpoint name="e:serviceHttpPort"
url="https://acompany.com"; />
</endpoints>
</soap11Binding>
</bindings>
in order not to create the default bidings (which are wrong) but to use
our own defined bindings which point correctly to a https url!
Well unfortunatelly it didn't worked; even if I see this in the
generated wsdl after this step:
<wsdl:service name="correctservice">
<wsdl:port name="correctserviceHttpPort"
binding="correctserviceSoap11Binding">
<wsdlsoap:address location="https://acompany.com"/>
</wsdl:port>
</wsdl:service>
I get this error when I try to validate the new generated wsdl (using
our own defined bindings):
"The 'serviceHttpPort' has an invalid binding - 'serviceSoap11Binding'.
Check that the 'serviceSoap11Binding' binding is defined."
Have to say that I checked the wsdl and the 'serviceSoap11Binding'
binding is CORRECTLY defined.
I would appreciate a feedback from the top level moderators of this
forum on this important issue.
There is any way in which we can can fix this through the config ?
To modify the library source class is not quite nice when you deploy
multiple web services ... then recompile the source etc ...
BTW: What Yogesh Chawla mentioned didn't worked for me = and I tried
that in the first place...; wrote the WSDL and generated stubs, then
client in the top-down design = needles to say, I ran into multiple
problems described in other threads, then tried to implement a
workaround to use original wsdl instead of generated one... = now I am
sure about the root cause = in this design the generated wsdl contains a
duplicate wrong schema (issue described as well in xfire jira bugs, but
from last autumn...) even if your wsdl is correct and contains a valid
schema = now taking that valid schema of that context putting it in a
Service.xsd and modifying the project to use the schema first apprach is
fixing this problem and the generated wsdl is correct; I managed to
bring up the service only by using this schema first approach/scenario.
I wonder how exactly you implemented your other suggestion Yogesh :
">> or published the actual WSDL generated by xfire as a
>> static page with the changes that I needed."
How exactly did you do this ?
">> Would something like that work for you?"
well it's easy to say that when we encounter so many obstacles, but I hope with
perseverence and some corroboration from the forum would work for me as well
and in a good design (not really having to modify that class for example...).
Regards,
Dragos
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
