cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Das, Santosh" <Santosh....@in.pega.com>
Subject RE: Information on using Interceptors in Service Side
Date Mon, 10 Mar 2014 12:12:14 GMT
Hi Andrei,

Again thanks for all the support you have provided till now.

Again as we were evaluating other approaches to use the functionality of CXF interceptors
directly in the  server side(Without CXF custom transport).

So the goal was to get the processed message out of the CXF inbound interceptors and the process
the message(just like we do in MySourcePayloadProvider) basically this interceptor has the
business logic  to do custom stuff and the modify the soapmessage and then set it back to
a place where the next interceptors in chain would pick the modified message(by our business
layer)

And  so we could see that CXF stack maintains an arraylist the 1st element is the key and
the second element is the stream.and we saw that MessageContentList.class was the key and
StaxSource wrapped stream was the 2nd element.
So we tried overwriting 
MessageContentsList list = (MessageContentsList) message
                                  .getContent(List.class);
                     if (list == null) {
                           list = new MessageContentsList();
                           message.setContent(List.class, list);
                     }
                     Reader reader = new StringReader(responseData);  -- Here we are creating
a reader with modified soap message which has been processed by our business layer
                     XMLInputFactory factory = XMLInputFactory.newInstance(); // Or
                                                                                         
                                  // newFactory()
                     XMLStreamReader xmlReader;

                     xmlReader = factory.createXMLStreamReader(reader);

                     list.set(0, new StaxSource(xmlReader));
                     message.getExchange().getOutMessage().setContent(List.class, list);
                     message.getExchange().getOutMessage()
                                  .setContent(OutputStream.class, new CachedOutputStream());
The concern we are having is we are trying to use Internal API's , although this is a core
logic in CXF for message retrieval in interceptors ,we fear that it could be changed.
Please provide your comments on this.

The reason I don’t want to go use CXF custom transport is that the invoke() of PegaServiceProvider
just has the argument as StackSource and there is no way I can share the objects related to
our business layer so that we can do processing inside invoke().
// 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();
> > 		}
> >

Let us know your opinion on this.

Also we were wondering why we are using a arraylist based implementation when we do MessageContentsList
list = (MessageContentsList) message
                                  .getContent(List.class);

The first element is the key and the 2nd element its value and so on and so for ,for other
objects in arraylist.
Is there any specific reason we did not use map for this purpose?

Thanks,
Santosh
-----Original Message-----
From: Andrei Shakirin [mailto:ashakirin@talend.com] 
Sent: Friday, February 28, 2014 2:16 PM
To: users@cxf.apache.org
Cc: Das, Santosh
Subject: RE: Information on using Interceptors in Service Side

Hi Santosh,


> We got the custom transport working.

Great!

> But before finalizing on the approach I wanted to understand if there 
> is any way we can directly get hold of the default interceptor chain 
> and add properties .This we want to do on service side.
> 
> It's like we want to use the interceptor logic via  API calls?

Ok, you would like to check if your initial approach can work. 
I would say theoretically it is possible: you could create the instances of interceptors,
put them into chain and initiate the message processing. The problem is that if you do that
decoupled from CXF call, it will be necessary to simulate a lot of things: CXF message, Bus,
extensions. You will be also dependent on internal CXF code that can be changed in next versions.
To be honest, I will not recommend this way. From my perspective custom transport solution
is more robust and clean.
Anyway to understand how it is implemented, look into ClientImpl.onMessage() for client side
and ChainInitiatorObserver.onMessage() for the service side.

Regards,
Andrei.

> 
> -----Original Message-----
> From: Andrei Shakirin [mailto:ashakirin@talend.com]
> Sent: Tuesday, February 25, 2014 8:51 PM
> To: users@cxf.apache.org
> Cc: Das, Santosh
> Subject: RE: Information on using Interceptors in Service Side
> 
> Hi,
> 
> See my answers bellow:
> 
> > -----Original Message-----
> > From: Das, Santosh [mailto:Santosh.Das@in.pega.com]
> > Sent: Dienstag, 25. Februar 2014 10:21
> > To: Andrei Shakirin; users@cxf.apache.org; Daniel Kulp
> > (dkulp@apache.org)
> > 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.validatePar
> > t(
> > DocLitera
> > lInInterceptor.java:253)
> > 	at
> > org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessa
> > ge
> > (DocLi
> > teralInInterceptor.java:191)
> > 	at
> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercep
> > to
> > rChai
> > n.java:308)
> > 	at
> > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInit
> > ia
> > tionOb
> > server.java:121)
> > 	at
> >
> org.sopera.cxf.transport.SBBDestination$SendJob.run(SBBDestination.jav
> a: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
> > .a
> > ccess
> > $301(Unknown Source)
> > 	at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
> > .r
> > un(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:ashakirin@talend.com]
> > Sent: Tuesday, February 25, 2014 1:41 PM
> > To: users@cxf.apache.org
> > 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:Santosh.Das@in.pega.com]
> > > Sent: Dienstag, 25. Februar 2014 08:39
> > > To: Daniel Kulp; users@cxf.apache.org; 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/s
> > > bb
> > > ",
> > > sbbTransport);
> > >
> > >
> > > dfm.registerDestinationFactory("http://schemas.xmlsoap.org/soap/ht
> > > tp
> > > ", sbbTransport);
> > >
> > > 	
> > > dfm.registerDestinationFactory("http://schemas.xmlsoap.org/wsdl/so
> > > a
> > > p/http", sbbTransport);
> > >
> > > 		ConduitInitiatorManager extension = 
> > > bus.getExtension(ConduitInitiatorManager.class);
> > >
> > >
> > > extension.registerConduitInitiator("http://cxf.apache.org/transpor
> > > ts
> > > /s
> > > b
> > > b", sbbTransport);
> > >
> > >
> > > extension.registerConduitInitiator("http://schemas.xmlsoap.org/soa
> > > p/
> > > h
> > > ttp", sbbTransport);
> > >
> > >
> > > extension.registerConduitInitiator("http://schemas.xmlsoap.org/wsd
> > > l/
> > > 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:dkulp@apache.org]
> > > Sent: Monday, February 24, 2014 9:58 PM
> > > To: users@cxf.apache.org; Das, Santosh
> > > Subject: Re: Information on using Interceptors in Service Side
> > >
> > >
> > > On Feb 24, 2014, at 11:14 AM, Das, Santosh 
> > > <Santosh.Das@in.pega.com>
> > > 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:ashakirin@talend.com]
> > > > Sent: Monday, February 24, 2014 1:38 PM
> > > > To: users@cxf.apache.org
> > > > 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:Santosh.Das@in.pega.com]
> > > > Sent: Freitag, 21. Februar 2014 11:54
> > > > To: Andrei Shakirin; users@cxf.apache.org
> > > > 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:ashakirin@talend.com]
> > > > Sent: Friday, February 21, 2014 4:01 PM
> > > > To: users@cxf.apache.org
> > > > 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:Santosh.Das@in.pega.com]
> > > > Sent: Donnerstag, 20. Februar 2014 10:48
> > > > To: Andrei Shakirin
> > > > Cc: users@cxf.apache.org
> > > > 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:renutcs@gmail.com]
> > > > 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 <ashakirin@talend.com>
> > > > Date: Thu, Feb 20, 2014 at 1:52 PM
> > > > Subject: RE: Information on using Interceptors in Service Side
> > > > To: "users@cxf.apache.org" <users@cxf.apache.org>
> > > > Cc: renu gupta <renutcs@gmail.com> 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-proj
> > > > ec
> > > > ts
> > > > .h
> > > > tml
> > > >
> > > > I  hope it is helpful.
> > > >
> > > > Regards,
> > > > Andrei.
> > > >
> > > >
> > > > From: renu gupta [mailto:renutcs@gmail.com]
> > > > 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 
> > > > <ashakirin@talend.com>
> > > 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:renutcs@gmail.com]
> > > > Sent: Mittwoch, 19. Februar 2014 16:31
> > > > To: users@cxf.apache.org; 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
> > > dkulp@apache.org - http://dankulp.com/blog Talend Community Coder 
> > > - http://coders.talend.com

Mime
View raw message