Could be an issue somewhere with your Karaf setup:
http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/, but that may
need determination. Two options:
1.) Deploy on the preconfigured Free & Open Source Talend ESB Standard
Edition (Karaf-based) container[1] and see if the web service works
there; if so, we know
there's some difference between your Karaf configuration and the
configuration done in Talend ESB, and research can be done there to see
what's wrong.
2.) Alternatively, try to load the web service provider contained in the
STS sample (last option of Step #3 in the README here: [2]) on to your
Karaf container and see if it works, if so, then the problem probably is
in your web service provider.
HTH,
Glen
[1] http://www.talend.com/products/esb-standard-edition.php
[2] https://github.com/Talend/tsf/tree/master/examples/jaxws-cxf-sts
On 02/09/2012 04:43 AM, Blue Diamond wrote:
Thanks for your response Glen.
The WSDL is correctly set. And yes we are running inside Karaf.
We also tried to put the WSDL file in the application classpath so that it
is visible to both CXF& our app and gave the wsdlLocation="myfile.wsdl"
... still the same problem. the service starts, but ?wsdl is not responding
correctly and CXF tries to handle it like a SOAP request intended for my
service.
Regards,
Anil
On Wed, Feb 8, 2012 at 6:36 PM, Glen Mazza<[email protected]> wrote:
Are you using Karaf? Also, are you sure you're using the correct URL to
access the WSDL? The endpoint URL is normally different between, say,
Tomcat deployment and Karaf deployment. For my blog's DoubleIt tutorial
for example, by default it would be http://localhost:8080/**
doubleit/services/doubleit<http://localhost:8080/doubleit/services/doubleit>(Tomcat)
vs. |
http://localhost:8080/**services/doubleit<http://localhost:8080/services/doubleit>(Karaf).|
Glen
On 02/08/2012 01:36 AM, Blue Diamond wrote:
Hello,
We are upgrading our CXF from 2.3.x to 2.5.x. We have our
WebServiceProviders implemented. Our components run in OSGi. Everything is
fine in 2.3.x where we used to embed CXF jars in our OSGi bundle.
Now, we want to use CXF bundles from OSGi thus making our service jars
thin.
Our WSDL is inside the bundle. So, after migration, these resources are
not
visible to the outside CXF. So, we tried to handle this with 2 different
apporaches
1. jaxwsCxfFactoryBean.setWSDLURL - service started successfully
2. In our WS provider impl, the annotation attribute wsdlLocation =
"http://....../ourWSDL";
- service started successfully
Both approaches made the service start but both have one main problem.
When we open the ?wsdl endpoint on the browser, it throws a 500 error& we
could see the following stacktrace on the server log. What I think is
happening is that, the ?wsdl request is being handle by CXF as a SOAP call
rather than a request for the WSDL document. Why could this be happening?
[qtp17003719-152 - /node/wsman?wsdl] phase.PhaseInterceptorChain --- -
Interceptor for -http://test/node}Node has thrown exception, unwinding
now.
org.apache.cxf.interceptor.**Fault: None of the policy alternatives can
be
satisfied.
at
org.apache.cxf.ws.policy.**AbstractPolicyInterceptor.**handleMessage(**
AbstractPolicyInterceptor.**java:47)[131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.phase.**PhaseInterceptorChain.**doIntercept(**
PhaseInterceptorChain.java:**263)[131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.transport.**ChainInitiationObserver.**onMessage(**
ChainInitiationObserver.java:**123)[131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.transport.http_**jetty.JettyHTTPDestination.**
serviceRequest(**JettyHTTPDestination.java:323)**[131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.transport.http_**jetty.JettyHTTPDestination.**doService(**
JettyHTTPDestination.java:289)**[131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.transport.http_**jetty.JettyHTTPHandler.handle(**
JettyHTTPHandler.java:72)[131
rg.apache.cxf.bundle:2.5.2]
at
org.eclipse.jetty.server.**handler.ContextHandler.**
doHandle(ContextHandler.java:**943)[99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at
org.eclipse.jetty.server.**handler.ContextHandler.**
doScope(ContextHandler.java:**879)[99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at
org.eclipse.jetty.server.**handler.ScopedHandler.handle(**
ScopedHandler.java:117)[99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at
org.eclipse.jetty.server.**handler.**ContextHandlerCollection.**handle(**
ContextHandlerCollection.java:**250)[99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at
org.eclipse.jetty.server.**handler.HandlerWrapper.handle(**
HandlerWrapper.java:110)[99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at org.eclipse.jetty.server.**Server.handle(Server.java:345)**[99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at
org.eclipse.jetty.server.**HttpConnection.handleRequest(**
HttpConnection.java:441)[99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at
org.eclipse.jetty.server.**HttpConnection$RequestHandler.**
headerComplete(HttpConnection.**java:919)[99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at org.eclipse.jetty.http.**HttpParser.parseNext(**
HttpParser.java:582)[95
rg.eclipse.jetty._http:7.5.4.**v20111024]
at org.eclipse.jetty.http.**HttpParser.parseAvailable(**
HttpParser.java:218)[95
rg.eclipse.jetty._http:7.5.4.**v20111024]
at
org.eclipse.jetty.server.**AsyncHttpConnection.handle(**
AsyncHttpConnection.java:51)[**99
rg.eclipse.jetty.server:7.5.4.**v20111024]
at
org.eclipse.jetty.io.nio.**SelectChannelEndPoint.handle(**
SelectChannelEndPoint.java:**586)[94
rg.eclipse.jetty.io:7.5.4.**v20111024]
at
org.eclipse.jetty.io.nio.**SelectChannelEndPoint$1.run(**
SelectChannelEndPoint.java:44)**[94
rg.eclipse.jetty.io:7.5.4.**v20111024]
at
org.eclipse.jetty.util.thread.**QueuedThreadPool.runJob(**
QueuedThreadPool.java:598)[93
rg.eclipse.jetty.util:7.5.4.**v20111024]
at
org.eclipse.jetty.util.thread.**QueuedThreadPool$3.run(**
QueuedThreadPool.java:533)[93
rg.eclipse.jetty.util:7.5.4.**v20111024]
at java.lang.Thread.run(Unknown Source)[:1.6.0_17]
Caused by: org.apache.cxf.ws.policy.**PolicyException: None of the policy
alternatives can be satisfied.
at
org.apache.cxf.ws.policy.**EffectivePolicyImpl.**chooseAlternative(**
EffectivePolicyImpl.java:171)[**131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.ws.policy.**EffectivePolicyImpl.**chooseAlternative(**
EffectivePolicyImpl.java:164)[**131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.ws.policy.**EffectivePolicyImpl.**initialise(**
EffectivePolicyImpl.java:109)[**131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.ws.policy.**PolicyEngineImpl.**
getEffectiveServerRequestPolic**y(PolicyEngineImpl.java:327)[**131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.ws.policy.**EndpointPolicyImpl.**initializeInterceptors(**
EndpointPolicyImpl.java:296)[**131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.ws.policy.**EndpointPolicyImpl.**getInterceptors(**
EndpointPolicyImpl.java:126)[**131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.ws.policy.**PolicyInInterceptor.handle(**
PolicyInInterceptor.java:140)[**131
rg.apache.cxf.bundle:2.5.2]
at
org.apache.cxf.ws.policy.**AbstractPolicyInterceptor.**handleMessage(**
AbstractPolicyInterceptor.**java:45)[131
rg.apache.cxf.bundle:2.5.2]
... 21 more
2012-02-07 15:25:41,312 WARN [qtp17003719-152 - /node/wsman?wsdl]
addressing.ContextUtils --- - WS-Addressing - failed to retrieve Message
Addressing Properties from context.
2012-02-07 15:25:41,312 WARN [qtp17003719-152 - /node/wsman?wsdl]
addressing.ContextUtils --- - WS-Addressing - failed to retrieve Message
Addressing Properties from context.
2012-02-07 15:25:41,312 WARN [qtp17003719-152 - /node/wsman?wsdl]
addressing.ContextUtils --- - WS-Addressing - failed to retrieve Message
Addressing Properties from context.
Any help is greatly appreciated. Thanks& Regards,
Anil
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza
