Guillaume Nodet wrote:
Yes, this is the reason why the servicemix-http component can not
generate a wsdl. It looks for a service and a port specified by then
jbi endpoint. I guess the jsr181 component should modify the
generated wsdl according to these informations. Could you please
raise a jira for that ?
In the mean time, you can change the soap-binding demo with the
following xbean files:
for the binding-su:
<?xml version="1.0"?>
<beans xmlns:http="http://servicemix.apache.org/http/1.0"
xmlns:demo="http://soap">
<http:endpoint service="demo:SimpleService"
endpoint="SimpleServiceJBIPort"
role="consumer"
locationURI="http://localhost:8192/Service/"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
soap="true" />
</beans>
and for the engine-su
<?xml version="1.0"?>
<beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0"
xmlns:demo="urn:servicemix:soap-binding">
<classpath>
<location>.</location>
</classpath>
<jsr181:endpoint pojoClass="soap.SimpleService"
annotations="none" />
</beans>
This way, you will be able to see the wsdl for the http proxy endpoint.
Cheers,
Guillaume Nodet
On 3/17/06, Tomas Olsson <[EMAIL PROTECTED]> wrote:
Now I saw that I got this warning when starting ServiceMix:
WARN - Jsr181Endpoint.registerService(279) | The endpoint name defined
in the wsdl (slaManagerJBIPort) does not match the endpoint name defined
in the endpoint spec (slaManager). WSDL description may be unusable.
I thought the WSDL was generated based on my input? I have exactly
copied the soap-binding example.
/Tomas
Tomas Olsson wrote:
When I try this:
http://localhost:9080/SLAManagerService//?WSDL
I get (even though I can see that internally there is a WSDL for my
jsr181-component):
------------
HTTP ERROR: 404
No wsdl is available for this service
RequestURI=/SLAManagerService/
/Powered by Jetty:// <http://jetty.mortbay.org>/
------------
Maybe this patch is not in the latest SNAPSHOT?
/Tomas
Guillaume Nodet wrote:
The servicemix-http component is also able to retrieve the wsdl from the
target JBI endpoint and to expose it (adding binding informations),
if none
is provided with the wsdlResource attribute. Currently, it only adds
the
http or soap address to the port of the service, but this is a
beginning ...
Cheers,
Guillaume Nodet
On 3/17/06, Eric Dofonsou <[EMAIL PROTECTED]> wrote:
I too had the same issue,
Right now I build my own endpoint that wraps around
the current endpoint and provide a mechanism to expose
WSDL when it receives a ?WSDL request on the
servicemix BC. However, the new servicemix-http
component has a way to expose WSDL via a wsdlResource
attribute (see :
http://docs.codehaus.org/display/SM/servicemix-http).
But this implies that you have a static WSDL file as a
spring ressource.
--- Robert Almonte <[EMAIL PROTECTED]> wrote:
Hi ServiceMix team,
I would like to know if it is possible to expose a
Web Service
externally (WSDL) using a BC that host the service
(using what
servicemix already provides).
I have been checking the soap-binding and
xfire-binding example, but I
still cannot get a whole picture to tie these two
together.
My scenario will be a Web Service that receives SOAP
requests for some
data and delegates internally using the NMR to other
components.
(e.i,: Soap-over-HTTP with WSDL exposed to client,
everything contained
by servicemix except the client)
Client <--> WebService{BC}<-->NMR---Other components
My scenario is close to the soap-binding example,
but this one doesn't
expose the WSDL externally.
The xfire-binding example exposes the WSDL
externally, but it is hosted
outside the servicemix.
Somebody posted about creating an Axis2 BC, but I
couldn't find more info.
Can anybody give me some guidance how I could do
this with the current
servicemix?
Thanks,
Robert
All information contained in this email is
confidential and may be used by the intended
recipient only.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Thank Guillaume,
Now the soap-binding generates the wsdl using your recommended
configuration.
Thanks,
Robert