2012/2/9 Daniel Kulp <[email protected]>: > On Thursday, February 09, 2012 3:13:47 PM 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. > > > Are there policy fragments in the WSDL that CXF may not understand? Thats > what it looks like the issue is. Since the wsdl is returned from an > interceptor on the chain, and the policies are processed very early in the > chain, they need to be resolvable.
I also suspected this. But I was not sure what the semantic or rule must be for the WSDL retrieval for a particular endpoint that enforces policy assertions. If you can't look up the WSDL, you won't know what assertions your request must satisfy in advance. In other words, shouldn't the WSDL retrieval call be handled differently from the normal soap binding soap request calls? regards, aki > > Dan > >> >> 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/doublei >> > t>(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 > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com
