Hi, See my answers bellow:
> -----Original Message----- > From: Das, Santosh [mailto:[email protected]] > Sent: Dienstag, 25. Februar 2014 10:21 > To: Andrei Shakirin; [email protected]; Daniel Kulp ([email protected]) > Subject: RE: Information on using Interceptors in Service Side > > Tried the same and getting same fault > > // TODO Auto-generated method stub > try{ > setUp(); > PegaServiceProvider hello = new PegaServiceProvider(); > String address = "http://localhost:9000/hello";; > Endpoint.publish(address, hello); > > > }catch(Exception e){ > e.printStackTrace(); > } > > > Result : > > WARNING: Interceptor for {http://esb.talend.org/}PegaServiceProviderService > has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: Message part {http://esb.talend.org/}sayHi > was not recognized. (Does it exist in service WSDL?) > at > org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLitera > lInInterceptor.java:253) > at > org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLi > teralInInterceptor.java:191) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai > n.java:308) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationOb > server.java:121) > at > org.sopera.cxf.transport.SBBDestination$SendJob.run(SBBDestination.java:193) > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown > Source) > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access > $301(Unknown Source) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(U > nknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Unknown Source) > > > PegaServiceProvider basically has > > @WebServiceProvider() > @ServiceMode(value = Service.Mode.PAYLOAD) > public class PegaServiceProvider implements Provider<Source> { > > public Source invoke(Source request) { > > System.out.println("invoke method ..."); > return null; > } > } > > As you mentioned . It seems that CXF doesn't recognize the message part in AbstractInDatabindingInterceptor.findMessagePart(). Could you please catch the wire SOAP request and post it here? Could you also try the same service without your custom transport, for example with HTTP? > > If I understood correctly the invoke() should have business logic and also its > responsibility is to build response. > Yes. > Then what is the purpose of having backchannelconduit , I think its purpose is > also to send the response. > > Correct me if I am wrong. Yes, backchannel conduit is for sending response from the service. > > And also could you explain what did you mean by " It is also possible to > combine > Provider<Source> with spring or blueprint jaxws:endpoint to create your > service." > I mean that you can use a spring way to register the service with the class implemented Provider<T>: <jaxws:endpoint xmlns:tns="myNamespace" implementor="mycompany. PegaServiceProvider" endpointName="tns:myEndpoint" serviceName="tns:myService" address="http://localhost:8080/services/myService";> </jaxws:endpoint> Regards, Andrei. > -----Original Message----- > From: Andrei Shakirin [mailto:[email protected]] > Sent: Tuesday, February 25, 2014 1:41 PM > To: [email protected] > Cc: Das, Santosh > Subject: RE: Information on using Interceptors in Service Side > > Hi Santosh, > > > I don’t want to use the service bean for the CXF framework to engage > > interceptors as we don’t have the privilege to generate such a bean. > > If I don’t use the bean its throwing error in DocLiteralInInterceptor > > in private void validatePart(MessagePartInfo p, QName elName, Message m) > { > > if (p == null) { > > throw new Fault(new > > org.apache.cxf.common.i18n.Message("NO_PART_FOUND", LOG, elName), > > Fault.FAULT_CODE_CLIENT); > > > > } > > How are you going to invoke business logic on the service side? > If JaxWsServerFactoryBean with setting service class and service bean doesn't > fit, you can consider to use generic service Provider<T> implementation: > > @WebServiceProvider() > @ServiceMode(value = Service.Mode.PAYLOAD) > public class MySourcePayloadProvider implements Provider<Source> { > > public Source invoke(Source request) { > ... > } > } > ... > Object implementor = new MySourcePayloadProvider(); String address = > "http://localhost:9000/SoapContext/SoapPort1";; > Endpoint.publish(address, implementor); > > In invoke() method you can call whatever you want to process request and > return the response. > It is also possible to combine Provider<Source> with spring or blueprint > jaxws:endpoint to create your service. > Custom transport will be registered in the same way in this case. > > Regards, > Andrei. > > > -----Original Message----- > > From: Das, Santosh [mailto:[email protected]] > > Sent: Dienstag, 25. Februar 2014 08:39 > > To: Daniel Kulp; [email protected]; Andrei Shakirin > > Subject: RE: Information on using Interceptors in Service Side > > > > Hi there, > > > > We tried out the JAXWSServerFactoryBean approach , and it worked > > however it doesn’t fit our requirement. > > Please look at this example we have tried out package > > org.sopera.cxf.test; > > > > > > > > import org.apache.cxf.Bus; > > import org.apache.cxf.BusFactory; > > import org.apache.cxf.bus.managers.DestinationFactoryManagerImpl; > > import org.apache.cxf.jaxws.JaxWsServerFactoryBean; > > import org.apache.cxf.transport.ConduitInitiatorManager; > > import org.junit.Before; > > import org.sopera.cxf.transport.SBBTransportFactory; > > import org.talend.esb.HelloWorldImpl; > > public class publishcxf1 { > > @Before > > public static void setUp() throws Exception { > > Bus bus = BusFactory.getDefaultBus(); > > // Other way to fix the problem > > // printRegistrations(bus); > > DestinationFactoryManagerImpl dfm = new > > DestinationFactoryManagerImpl(bus); > > SBBTransportFactory sbbTransport = new > SBBTransportFactory(); > > > > > > dfm.registerDestinationFactory("http://cxf.apache.org/transports/sbb";, > > sbbTransport); > > > > dfm.registerDestinationFactory("http://schemas.xmlsoap.org/soap/http > > ", sbbTransport); > > > > dfm.registerDestinationFactory("http://schemas.xmlsoap.org/wsdl/soa > > p/http", sbbTransport); > > > > ConduitInitiatorManager extension = > > bus.getExtension(ConduitInitiatorManager.class); > > > > > > extension.registerConduitInitiator("http://cxf.apache.org/transports/s > > b > > b", sbbTransport); > > > > extension.registerConduitInitiator("http://schemas.xmlsoap.org/soap/h > > ttp", sbbTransport); > > > > extension.registerConduitInitiator("http://schemas.xmlsoap.org/wsdl/s > > oap/http", sbbTransport); > > } > > /** > > * @param args > > */ > > public static void main(String[] args) { > > // TODO Auto-generated method stub > > try{ > > setUp(); > > HelloWorldImpl hello = new HelloWorldImpl(); > > JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean(); > > sf.setServiceBean(hello); // don’t want to do this > > because we don’t have a bean and our design doesn’t allow it. > > sf.setStart(true); > > sf.setBus(BusFactory.getDefaultBus(true)); > > sf.create(); > > > > > > }catch(Exception e){ > > e.printStackTrace(); > > } > > > > } > > > > } > > > > As I said previously we have custom layers which is a servlet based > > implementation and we get hold of the request envelope. > > I don’t want to use the service bean for the CXF framework to engage > > interceptors as we don’t have the privilege to generate such a bean. > > If I don’t use the bean its throwing error in DocLiteralInInterceptor > > in private void validatePart(MessagePartInfo p, QName elName, Message m) > { > > if (p == null) { > > throw new Fault(new > > org.apache.cxf.common.i18n.Message("NO_PART_FOUND", LOG, elName), > > Fault.FAULT_CODE_CLIENT); > > > > } > > > > Is it possible not to engage interceptors in the service side if we > > don’t have a service bean. Basically not doing > > sf.setServiceBean(hello); > > > > we have evaluated CXF for our client side and able to leverage the > > power of interceptors using dispatch API. > > However we're kind of stuck at service side. > > > > Please let us know how we could use this in our implementation which > > is not a JAX-ws based implementation. > > > > > > Thanks, > > Santosh > > > > > > > > > > -----Original Message----- > > From: Daniel Kulp [mailto:[email protected]] > > Sent: Monday, February 24, 2014 9:58 PM > > To: [email protected]; Das, Santosh > > Subject: Re: Information on using Interceptors in Service Side > > > > > > On Feb 24, 2014, at 11:14 AM, Das, Santosh <[email protected]> > > wrote: > > > > > Hi Andrei, > > > > > > While trying out the approach of custom conduit I wanted to know if > > > the entry point of code can be anything other than > > > Endpoint.publish() > > > > Yes. Kind of. > > > > You can use the JaxWsServerFactoryBean to create CXF server objects which > > represent the service and manipulate that. The normal JAX-WS Endpoint > > object pretty much just wrappers an Server object so MOST of the > functionality > > would be there. However, it’s not an “javax.xml.ws.Endpoint” object and > thus > > code that expects that could be problematic. > > > > Alternatively, just "new org.apache.cxf.jaxws.EndpointImpl(….)”. > > > > > > Dan > > > > > > > > > > > > What we saw is if we register create a custom destination and > > > conduit and > > resister custom transport it eventually kicks in the interceptor chain. > > > Is there any other way of engaging the interceptors? > > > > > > > > > > > > Thanks > > > Santosh > > > > > > -----Original Message----- > > > From: Andrei Shakirin [mailto:[email protected]] > > > Sent: Monday, February 24, 2014 1:38 PM > > > To: [email protected] > > > Cc: Das, Santosh > > > Subject: RE: Information on using Interceptors in Service Side > > > > > > Hi Santosh, > > > > > > > > >> Excellent! That’s close to what we need. > > > > > > Nice, Btw I have the similar use case in the past: customer required > > > the wire > > compatibility with legacy ESB applications (speaking SOAP with some > > proprietary extensions), but would like to use CXF and JAX-WS as > > frontend. It was resolved and implemented using CXF custom transport. > > > > > >> Also could you please guide to some articles which describes about > > >> saml > > token validation at service side. > > > > > > I would start with a link to Glen's blog I already sent Renu: SAML > > > using ws- > > policy: http://www.jroller.com/gmazza/entry/cxf_sts_tutorial . It > > covers obtaining and validation of SAML token using STS service. > > > > > > Regards, > > > Andrei. > > > > > > > > > So you are going to keep your own transport layer receiving and > > > sending soap > > messages: > > >> Servlet → getting the request soap envelope (custom layer ,don’t > > >> want to use CXF) generate response (again custom layer and don’t > > >> want > > >> CXF) > > > > > > Did I get that correctly? > > > > > > In this case I would consider to implement custom transport in CXF. > > > You will > > be able to wrap your custom layer into CXF Destination and Conduit. > > > The interceptor chain with security features will work natively in this > > > case. > > > Look my blog for details: > > > http://ashakirin.blogspot.de/2012/02/custom-cxf-transport.html > > > > > > Regards, > > > Andrei. > > > > > > From: Das, Santosh [mailto:[email protected]] > > > Sent: Freitag, 21. Februar 2014 11:54 > > > To: Andrei Shakirin; [email protected] > > > Subject: RE: Information on using Interceptors in Service Side > > > > > > Hi Andrei, > > > > > > No the idea is to swap out both XWSS api and SAML processing and > > > use CXF > > layer in service side. > > > So does CXF exposes API’s directly so that I could engage only > > > interceptors I > > am interested in and get the functionality. > > > > > > The flow is like this > > > > > > Servlet → getting the request soap envelope (custom layer ,don’t > > > want to use CXF)→engage CXF api’s directly or via interceptors(here > > > we want to use CXF features like SAML validation, Ws-Security stuff) > > > →generate response (again custom layer and don’t want CXF) > > > > > > Hope scenario is clear now. > > > > > > Please provide your suggestions. > > > > > > > > > Thanks, > > > Santosh > > > > > > From: Andrei Shakirin [mailto:[email protected]] > > > Sent: Friday, February 21, 2014 4:01 PM > > > To: [email protected] > > > Cc: Das, Santosh > > > Subject: RE: Information on using Interceptors in Service Side > > > > > > Hi Santosh, > > > > > > As I understood you are going to keep XWSS API on client and service > > > sides, > > but would like to reuse some CXF functionality for SAML processing on > > the service side (SAML validation, holder of key check, etc). > > > So the aim is not to migrate service side to CXF completely, but > > > just reuse > > some security functionality from it. > > > Is my understanding correct? > > > > > > I see three options here: > > > A) Provide kind of CXF layer on the service side, that will receive > > > messages > > from wire, validate security and SAML and pass SOAP messages to XWSS > > API implementation. Vice versa for outgoing chain: SOAP messages will > > be prepared in XWSS API service, CXF will be called with prepared > > message, apply necessary security and send message. CXF layer will > > include complete CXF interceptors chain and transport. > > > B) Implement generic CXF gateway. CXF gateway will receive SOAP > > > messages, validate them and redirect to XWSS services. Vice versa > > > for outgoing chain > > > C) Try to reuse only specific CXF interceptors functionality > > > directly from XWSS > > services. Seems to be involved, because CXF security interceptors has > > some dependencies on CXF API and core. > > > > > > Regards, > > > Andrei. > > > > > > From: Das, Santosh [mailto:[email protected]] > > > Sent: Donnerstag, 20. Februar 2014 10:48 > > > To: Andrei Shakirin > > > Cc: [email protected] > > > Subject: FW: Information on using Interceptors in Service Side > > > > > > Hi Andrei, > > > > > > First of all many thanks for the help and support you have been providing. > > > > > > This is in continuation to the discussion below regarding CXF being > > > used in > > server side. > > > > > > As Renu already mentioned we have a custom implementation of soap > > services which is not JAX-WS based , we are using XWSS API (a > > subproject of > > metro) and WSS4J directly for SAML processing. > > > > > > Is there any direct API which CXF exposes which can be used in the > > > service > > side to do ws-security processing, saml validation , etc. > > > > > > Basically we want to use the INInterceptors in the service side and > > > the > > engage the out interceptors after generating the soap response. > > Typically the highlighted portion of the diagram. > > > We are not interested to publish the service either as we have our > > > own > > implementation so cant use the Enpoint api. > > > > > > > > > We are kind of stuck and wondering if CXF could be of any help Out > > > of the > > box. > > > > > > Please advise. > > > > > > > > > > > > > > > > > > From: renu gupta [mailto:[email protected]] > > > Sent: Thursday, February 20, 2014 2:49 PM > > > To: Das, Santosh > > > Subject: Fwd: Information on using Interceptors in Service Side > > > > > > FYI > > > > > > Thanks, > > > Renu > > > ---------- Forwarded message ---------- > > > From: Andrei Shakirin <[email protected]> > > > Date: Thu, Feb 20, 2014 at 1:52 PM > > > Subject: RE: Information on using Interceptors in Service Side > > > To: "[email protected]" <[email protected]> > > > Cc: renu gupta <[email protected]> > > > Hi, > > > > > > If you will use ws-policy, it is enough to attach (embed) the policy > > > into WSDL > > and configure necessary security parameters like keystores and alias. > > > CXF will care about activation of necessary interceptors automatically. > > > > > > I would recommend you to look in Glen Mazza blogs: > > > - UsernameToken security using ws-policy > > http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile > > > - SAML using ws-policy: > > http://www.jroller.com/gmazza/entry/cxf_sts_tutorial > > > > > > Just make that step by step, you will have a filling how it works CXF. > > > If you like to understand internal ws-policy mechanisms in CXF, > > > refer my blog: > > > http://ashakirin.blogspot.de/2012/02/using-ws-policy-in-cxf-projects > > > .h > > > tml > > > > > > I hope it is helpful. > > > > > > Regards, > > > Andrei. > > > > > > > > > From: renu gupta [mailto:[email protected]] > > > Sent: Donnerstag, 20. Februar 2014 06:09 > > > To: Andrei Shakirin > > > Subject: Re: Information on using Interceptors in Service Side > > > > > > The link which you have given talks about configuration at connector > > > end but I > > want to know how we can leverage the interceptors at services end. We > > are having our custom implementation which takes care of invocation of > > service, publishing it and doing authentication and we uses Metro for > > security feature, we want to use CXF instead of Metro and wss4j. So we > > don't want to change the whole implementation of the Services we have > > now , but just want to hook in CXF interceptors or API's if available > > to do the validation etc for the Security/ Addressing and SAML case. > > > > > > > > > Thanks, > > > Renu > > > > > > On Wed, Feb 19, 2014 at 9:50 PM, Andrei Shakirin > > > <[email protected]> > > wrote: > > > Hi, > > > > > > There are different ways to do that: > > > a) using ws-policy – recommended way > > > b) using features (WS-Addressing) and security actions configuration > > (security) > > > c) configure interceptors in client/endpoint or bus level > > > d) add interceptors dynamically for code > > > > > > I would prefer alternative (a) for WSA and SAML > > (http://cxf.apache.org/docs/ws-securitypolicy.html), but final > > decision depends on your requirements. > > > > > > Regards, > > > Andrei. > > > > > > From: renu gupta [mailto:[email protected]] > > > Sent: Mittwoch, 19. Februar 2014 16:31 > > > To: [email protected]; Andrei Shakirin > > > Subject: Information on using Interceptors in Service Side > > > > > > Hi , > > > > > > We are having our own custom service implementation which takes care > > > of > > publishing the wsdl. We were using the Metro for the security feature > > and wss4j for the SAML support. As we are planning to leverage CXF. I > > have some doubts : > > > How can we use the interceptors to achieve the particular feature > > > like WS > > Addressing , SAML . Does CXF provides the API’s directly which we can hook ? > > > > > > Thanks, > > > Renu > > > > > > > > > > -- > > Daniel Kulp > > [email protected] - http://dankulp.com/blog Talend Community Coder - > > http://coders.talend.com
