Interceptors
I have created an interceptor (AbstractPhaseInterceptor) that is used by two Web services. One of the functions of the interceptor is to intercept faults from outbound requests to a third web service when the third service is not available. When one service runs it all functions correctly but when two are running the exceptions are dumped to the log as if the interceptor was not there. Since this is a polling application the exception can be annoying. -- View this message in context: http://www.nabble.com/Interceptors-tp16476100p16476100.html Sent from the cxf-user mailing list archive at Nabble.com.
Configuring Interceptors
Hi all, I understand the way of plugging in In and Out Interceptors to CXF bus like, We can specify a set of configuration inside each of WSS4J In and Out interceptors. My requirement is to specify an alternative configuration also along with this configuration. So, if service configured for configuration A and B. If the incoming message adheres to Configuration B rather than A, CXFBus can pass the message to WSSInInterceptor configured for B configuration, without WSSInInterceptor A giving Security Failure. Is it somehow feasible using CXF Spring Configuration or the way we specify Interceptors to CXFBus? With Regards, Mayank
Re: Interceptors
I'm confused--"intercept faults from outbound requests to a third web service when the third service is not available" If the third web service was not available, how could it be returning faults to your other two web services' requests? Glen Am Donnerstag, den 03.04.2008, 16:10 -0700 schrieb Web Man: > I have created an interceptor (AbstractPhaseInterceptor) that is used by two > Web services. One of the functions of the interceptor is to intercept > faults from outbound requests to a third web service when the third service > is not available. When one service runs it all functions correctly but when > two are running the exceptions are dumped to the log as if the interceptor > was not there. Since this is a polling application the exception can be > annoying.
Re: Interceptors
I have two WS (WS1 and WS2) running on a Jboss server. They have nothing to do with each other except that they use CXF. WS2 has a CXF client built in (WSDL2Java) that makes periodic calls to the third WS3. When WS3 is not there, the following errors appear in the log. I have removed all inbound and outbound logging interceptors in the SrpingBeans.xml for WS1 ad WS2. When WS1 is not running there are no errors generated. 10:12:52,635 ERROR [STDERR] Apr 4, 2008 10:12:52 AM org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Could not send Message. at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende rInterceptor.java:64) Glen Mazza-2 wrote: > > I'm confused--"intercept faults from outbound requests to a third web > service when the third service is not available" If the third web > service was not available, how could it be returning faults to your > other two web services' requests? > > Glen > > Am Donnerstag, den 03.04.2008, 16:10 -0700 schrieb Web Man: >> I have created an interceptor (AbstractPhaseInterceptor) that is used by >> two >> Web services. One of the functions of the interceptor is to intercept >> faults from outbound requests to a third web service when the third >> service >> is not available. When one service runs it all functions correctly but >> when >> two are running the exceptions are dumped to the log as if the >> interceptor >> was not there. Since this is a polling application the exception can be >> annoying. > > > -- View this message in context: http://www.nabble.com/Interceptors-tp16476100p16491556.html Sent from the cxf-user mailing list archive at Nabble.com.
RE: Configuring Interceptors
If I understand your question correctly, you want to dispatch incoming request to two different instances of WSSInInterceptor which are configured differently, and the dispatch criteria is based on some information in the incoming request. If this is case, what you are really looking for is a content-based-routing, i.e., you route incoming messages to different endpoints. For example, you can have two endpoints that are configured using different interceptors. A system test located under trunk\systests\src\test\java\org\apache\cxf\systest\versioning shows you to do a basic routing in CXF. Hope this helps, Jervis > -Original Message- > From: Mayank Mishra [mailto:[EMAIL PROTECTED] > Sent: 2007?10?16? 21:03 > To: cxf-user@incubator.apache.org > Subject: Configuring Interceptors > > > Hi all, > > I understand the way of plugging in In and Out Interceptors > to CXF bus like, > > > > > > > > > > > > > > > > ... > > We can specify a set of configuration inside each of WSS4J In and Out > interceptors. > > My requirement is to specify an alternative configuration also along > with this configuration. So, if service configured for > configuration A > and B. If the incoming message adheres to Configuration B > rather than A, > CXFBus can pass the message to WSSInInterceptor configured for B > configuration, without WSSInInterceptor A giving Security Failure. > > Is it somehow feasible using CXF Spring Configuration or the way we > specify Interceptors to CXFBus? > > With Regards, > Mayank > IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Configuring Interceptors
You would probably need to write your own interceptor that would
determine the appropriate configuration and then adds that to the chain.
Basically, write an interceptor that does:
public void handleMessage(Message message) {
SOAPMessage msg = message.getContent(SOAPMessage.class);
if (messageConformsToA(msg)) {
message.getInterceptorChain().add(wss4jAInterceptor);
} else {
message.getInterceptorChain().add(wss4jBInterceptor);
}
}
You would then configure your interceptor in the chains in the spring
config.
Enjoy!
Dan
On Tuesday 16 October 2007, Mayank Mishra wrote:
> Hi all,
>
> I understand the way of plugging in In and Out Interceptors to CXF bus
> like,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...
>
> We can specify a set of configuration inside each of WSS4J In and Out
> interceptors.
>
> My requirement is to specify an alternative configuration also along
> with this configuration. So, if service configured for configuration A
> and B. If the incoming message adheres to Configuration B rather than
> A, CXFBus can pass the message to WSSInInterceptor configured for B
> configuration, without WSSInInterceptor A giving Security Failure.
>
> Is it somehow feasible using CXF Spring Configuration or the way we
> specify Interceptors to CXFBus?
>
> With Regards,
> Mayank
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Configuring Interceptors
Hi CXF provides a flexible configuration of interceptor. You can configure the interceptor in Bus level or in Endpoint level. For you case, I think you can define the WSS4J interceptor in your Endpoint B, and add the SAAJ*Interceptor in the bus. In this way, the EndpointA will not check the security any more. Willem. Mayank Mishra wrote: Hi all, I understand the way of plugging in In and Out Interceptors to CXF bus like, We can specify a set of configuration inside each of WSS4J In and Out interceptors. My requirement is to specify an alternative configuration also along with this configuration. So, if service configured for configuration A and B. If the incoming message adheres to Configuration B rather than A, CXFBus can pass the message to WSSInInterceptor configured for B configuration, without WSSInInterceptor A giving Security Failure. Is it somehow feasible using CXF Spring Configuration or the way we specify Interceptors to CXFBus? With Regards, Mayank
Extending Security Interceptors
I'm implementing a simple web service using Apache CXF where I have to authenticate a user based on username and password. This is straightforward and I have the service working using the WSS4F Interceptors. The next phase of the project is making the service able to choose from a list of auth dbs where it will get the encrypted password that WSS4J will then use to compare against the password sent in the SOAP header. In order to determine which DB to pull the auth data from, I'd like to add a new header to the SOAP message. The Interceptor/Callbackhandler should have access to this header and then use it to figure out which DB to connect to. If anyone has any tips on how to approach this using the CXF API, please let me know! Thanks! -- View this message in context: http://www.nabble.com/Extending-Security-Interceptors-tf4778795.html#a13670686 Sent from the cxf-user mailing list archive at Nabble.com.
interceptors and faults
hi all, I'm writing a automated system for monitoring certain quality of service properties (e.g., response time, etc) from a client-side perspective. this works quite well as long as no fault occur on the service provider that i'm trying to invoke. I use a couple of interceptors in the IN and OUT chains to achieve it. in case of a fault that occurs on the server, I need to be aware of this fault at the client side (e.g., I need to log the fault message etc into a database). the problem I'm struggling with it the following: if a fault occurs on the server my incoming interceptor chain at the client side is not processed to the latest phase where I have my interceptor that stores all the stuff into the database. the interceptor chain stops after the READ phase on my client (thats what I could see in the debugger). I've experimented a bit with a simple interceptor that just dumps a message to the console upon calling handleMessage() and handleFault(). I've added to every phase in the IN and FAULT chain, nevertheless handleFault() is never called upon receiving a fault message from the server. could someone please clarify how faults from the server can be handled in the client-side interceptor chains (i'm using cxf v2.05)? thanks, -Florian
Configuring interceptors using annotations
Is there support for configuring interceptors using annotations? I'm looking for something like the org.codehaus.xfire.annotations.InHandlers and org.codehaus.xfire.annotations.OutHandlers class where were present in XFire. I'm thinking of writing similar annotations and want to make sure that the work hasn't already been done. Thanks. Zarar -- View this message in context: http://www.nabble.com/Configuring-interceptors-using-annotations-tf4097300.html#a11650715 Sent from the cxf-user mailing list archive at Nabble.com.
Message.getContent(???) options for interceptors
Hello, I have a question about the org.apache.cxf.message.Message.getContent(?) method within interceptors. The CXF sample interceptor[1] on line 49 has this call to get the content (payload) of the SOAP message: OutputStream os = message.getContent(OutputStream.class); Question: Besides "OutputStream.class", what other options do I have as the argument to getContent() for a message that comes from an interceptor's handleMessage(Message m) or handleFault(Message m)? (Also, does anyone know where in the CXF source code that list of acceptable classes is defined? Understanding the source may help me here.) Thanks, Glen [1] http://tinyurl.com/yqz58p
Re: interceptors and faults
Server faults go into separate interceptor chains (second paragraph of [1])--I have not done this before, but you should be able to reuse the interceptors you have on your normal non-error chains for the error situations. HTH, Glen [1] http://cwiki.apache.org/CXF20DOC/interceptors.html Am Mittwoch, den 09.04.2008, 11:14 +0200 schrieb Florian Rosenberg: > hi all, > > I'm writing a automated system for monitoring certain quality of service > properties (e.g., response time, etc) from a client-side perspective. > this works quite well as long as no fault occur on the service provider > that i'm trying to invoke. I use a couple of interceptors in the IN and > OUT chains to achieve it. > > in case of a fault that occurs on the server, I need to be aware of this > fault at the client side (e.g., I need to log the fault message etc into > a database). > > the problem I'm struggling with it the following: if a fault occurs on > the server my incoming interceptor chain at the client side is not > processed to the latest phase where I have my interceptor that stores > all the stuff into the database. the interceptor chain stops after the > READ phase on my client (thats what I could see in the debugger). > > I've experimented a bit with a simple interceptor that just dumps a > message to the console upon calling handleMessage() and handleFault(). > I've added to every phase in the IN and FAULT chain, nevertheless > handleFault() is never called upon receiving a fault message from the > server. > > could someone please clarify how faults from the server can be handled > in the client-side interceptor chains (i'm using cxf v2.05)? > > thanks, > -Florian >
Re: interceptors and faults
hi glen, Glen Mazza wrote: Server faults go into separate interceptor chains (second paragraph of [1])--I have not done this before, but you should be able to reuse the interceptors you have on your normal non-error chains for the error situations. so you mean the FAULT chain? i've added my interceptor everywhere but AFAIR the fault chain interceptors are not invoked and all interceptors in the IN chain stop after the READ phase (in case of the server fault) -Florian [1] http://cwiki.apache.org/CXF20DOC/interceptors.html Am Mittwoch, den 09.04.2008, 11:14 +0200 schrieb Florian Rosenberg: hi all, I'm writing a automated system for monitoring certain quality of service properties (e.g., response time, etc) from a client-side perspective. this works quite well as long as no fault occur on the service provider that i'm trying to invoke. I use a couple of interceptors in the IN and OUT chains to achieve it. in case of a fault that occurs on the server, I need to be aware of this fault at the client side (e.g., I need to log the fault message etc into a database). the problem I'm struggling with it the following: if a fault occurs on the server my incoming interceptor chain at the client side is not processed to the latest phase where I have my interceptor that stores all the stuff into the database. the interceptor chain stops after the READ phase on my client (thats what I could see in the debugger). I've experimented a bit with a simple interceptor that just dumps a message to the console upon calling handleMessage() and handleFault(). I've added to every phase in the IN and FAULT chain, nevertheless handleFault() is never called upon receiving a fault message from the server. could someone please clarify how faults from the server can be handled in the client-side interceptor chains (i'm using cxf v2.05)? thanks, -Florian -- Florian Rosenberg Research Assistant Distributed Systems Group Technical University Vienna, Austria tel: +43 1 58801 18418 fax: +43 1 58801 18491 www.florianrosenberg.com "keep in mind that my knowledge of the issues is very limited, fragmented and quite possibly completely wrong" A.S.
Re: interceptors and faults
On Wednesday 09 April 2008, Florian Rosenberg wrote: > hi glen, > > Glen Mazza wrote: > > Server faults go into separate interceptor chains (second paragraph > > of [1])--I have not done this before, but you should be able to > > reuse the interceptors you have on your normal non-error chains for > > the error situations. > > so you mean the FAULT chain? i've added my interceptor everywhere but > AFAIR the fault chain interceptors are not invoked and all > interceptors in the IN chain stop after the READ phase (in case of the > server fault) This is slightly changing in 2.0.6/2.1 as it may go a little bit furthur into the IN chain, but it won't go all the way. Basically, when a message comes in, it starts out on the IN chain. At some point along the chain (always was in the ReadHeadersInterceptor in 2.0.5, but will be furthur along in 2.0.6/2.1 in order to get ws-security to fully digest the whole body), it checks if the soap:body child is a soap:fault. If so, it stops the In chain and re-dispatches on the IN FAULT chain. Keep in mind, there are two fault chains. There is an OUT fault chain on the server and an IN fault chain on the client. Make sure you add to the right chain. Dan > > -Florian > > > [1] http://cwiki.apache.org/CXF20DOC/interceptors.html > > > > Am Mittwoch, den 09.04.2008, 11:14 +0200 schrieb Florian Rosenberg: > >> hi all, > >> > >> I'm writing a automated system for monitoring certain quality of > >> service properties (e.g., response time, etc) from a client-side > >> perspective. this works quite well as long as no fault occur on the > >> service provider that i'm trying to invoke. I use a couple of > >> interceptors in the IN and OUT chains to achieve it. > >> > >> in case of a fault that occurs on the server, I need to be aware of > >> this fault at the client side (e.g., I need to log the fault > >> message etc into a database). > >> > >> the problem I'm struggling with it the following: if a fault occurs > >> on the server my incoming interceptor chain at the client side is > >> not processed to the latest phase where I have my interceptor that > >> stores all the stuff into the database. the interceptor chain stops > >> after the READ phase on my client (thats what I could see in the > >> debugger). > >> > >> I've experimented a bit with a simple interceptor that just dumps a > >> message to the console upon calling handleMessage() and > >> handleFault(). I've added to every phase in the IN and FAULT chain, > >> nevertheless handleFault() is never called upon receiving a fault > >> message from the server. > >> > >> could someone please clarify how faults from the server can be > >> handled in the client-side interceptor chains (i'm using cxf > >> v2.05)? > >> > >> thanks, > >> -Florian -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: interceptors and faults
Daniel Kulp wrote:
On Wednesday 09 April 2008, Florian Rosenberg wrote:
hi glen,
Glen Mazza wrote:
Server faults go into separate interceptor chains (second paragraph
of [1])--I have not done this before, but you should be able to
reuse the interceptors you have on your normal non-error chains for
the error situations.
so you mean the FAULT chain? i've added my interceptor everywhere but
AFAIR the fault chain interceptors are not invoked and all
interceptors in the IN chain stop after the READ phase (in case of the
server fault)
This is slightly changing in 2.0.6/2.1 as it may go a little bit furthur
into the IN chain, but it won't go all the way. Basically, when a
message comes in, it starts out on the IN chain. At some point along
the chain (always was in the ReadHeadersInterceptor in 2.0.5, but will
be furthur along in 2.0.6/2.1 in order to get ws-security to fully
digest the whole body), it checks if the soap:body child is a
soap:fault. If so, it stops the In chain and re-dispatches on the IN
FAULT chain. Keep in mind, there are two fault chains. There is an
OUT fault chain on the server and an IN fault chain on the client. Make
sure you add to the right chain.
As I said, I've added my DummyInterceptor to every phase in every chain
(IN, OUT, IN-FAULT, OUT-FAULT) but a service side exception does not go
further than the IN_READ phase (where the handleMessage methods is
invoked) then it stops processing the chains and I see an error from my
JaxWsProxyFactoryBean in the client.
Any advise why the fault chain is not invoked? Below you find an sample
main method that invokes an ErrorService with a buggyOperation() that
always throws a custom exception (DummyException) and its output. The
SimpleInterceptor just dumps each invocation of "handleMessage" and
"handleFault" to the console.
I don't understand why the fault chain is never invoked in this case.
Any advise would be helpful how to configure/code this stuff correctly.
I'm using the CXF 2.1 SNAPSHOT
-Florian
public static void main(String[] args) {
ClientProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setAddress("http://localhost:1/ErrorService";);
factory.setServiceClass(ErrorService.class);
ErrorService ess = (ErrorService)factory.create();
Client c = ClientProxy.getClient(ess);
List infault = c.getInFaultInterceptors();
infault.add(new SimpleInterceptor(Phase.RECEIVE));
infault.add(new SimpleInterceptor(Phase.PRE_STREAM));
infault.add(new SimpleInterceptor(Phase.PRE_PROTOCOL));
infault.add(new SimpleInterceptor(Phase.UNMARSHAL));
infault.add(new SimpleInterceptor(Phase.PRE_LOGICAL));
infault.add(new SimpleInterceptor(Phase.PRE_INVOKE));
List in = c.getInInterceptors();
in.add(new SimpleInterceptor(Phase.RECEIVE));
in.add(new SimpleInterceptor(Phase.PRE_STREAM));
in.add(new SimpleInterceptor(Phase.PRE_PROTOCOL));
in.add(new SimpleInterceptor(Phase.UNMARSHAL));
in.add(new SimpleInterceptor(Phase.PRE_LOGICAL));
in.add(new SimpleInterceptor(Phase.PRE_INVOKE));
try {
ess.buggyOperation("something wrong");
} catch (DummyException_Exception e) {
e.printStackTrace();
}
}
Output:
--
Apr 16, 2008 2:17:31 PM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
INFO: No cxf.xml configuration file detected, relying on defaults.
Apr 16, 2008 2:17:32 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://services.quatsch/}ErrorServiceService
from class quatsch.services.ErrorService
SimpleInterceptor::handleMessage() invoked in phase 'receive' invoked
SimpleInterceptor::handleMessage() invoked in phase 'pre-stream' invoked
SimpleInterceptor::handleMessage() invoked in phase 'pre-protocol' invoked
quatsch.services.DummyException_Exception: Error occured: something wrong
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:184)
at $Proxy37.buggyOperation(Unknown Source)
at cxf.test.ErrorServiceClient.main(ErrorServiceClient.java:41)
Re: interceptors and faults
Florian Rosenberg wrote:
[...]
public static void main(String[] args) {
ClientProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setAddress("http://localhost:1/ErrorService";);
factory.setServiceClass(ErrorService.class);
ErrorService ess = (ErrorService)factory.create();
Client c = ClientProxy.getClient(ess);
List infault = c.getInFaultInterceptors();
infault.add(new SimpleInterceptor(Phase.RECEIVE));
infault.add(new SimpleInterceptor(Phase.PRE_STREAM));
infault.add(new SimpleInterceptor(Phase.PRE_PROTOCOL));
infault.add(new SimpleInterceptor(Phase.UNMARSHAL));
infault.add(new SimpleInterceptor(Phase.PRE_LOGICAL));
infault.add(new SimpleInterceptor(Phase.PRE_INVOKE));
List in = c.getInInterceptors();
in.add(new SimpleInterceptor(Phase.RECEIVE));
in.add(new SimpleInterceptor(Phase.PRE_STREAM));
in.add(new SimpleInterceptor(Phase.PRE_PROTOCOL));
in.add(new SimpleInterceptor(Phase.UNMARSHAL));
in.add(new SimpleInterceptor(Phase.PRE_LOGICAL));
in.add(new SimpleInterceptor(Phase.PRE_INVOKE));
try {
ess.buggyOperation("something wrong");
} catch (DummyException_Exception e) {
e.printStackTrace();
}
}
found the problem, very subtile: you need to invoke
factory.getClientFactoryBean().get[In|Out|InFault|OutFault]Interceptors();
on the client factory bean not directly on the factory, then it works.
Is this desired behavior? Besides that, I still do not really unterstand
when handleFault() is called in an interceptor and what are the
consequences
Thanks,
-Florian
Re: Configuring interceptors using annotations
Hi Zarar, As part of its JAXWS implementation CXF supports the @javax.jws.HandlerChain annotation for JAX-WS handlers. There are no custom annotations in CXF that allow to specify inbound/outbound fault/message interceptors (i.e. CXF handlers) .. Regards, Andrea. Zarar Siddiqi wrote: Is there support for configuring interceptors using annotations? I'm looking for something like the org.codehaus.xfire.annotations.InHandlers and org.codehaus.xfire.annotations.OutHandlers class where were present in XFire. I'm thinking of writing similar annotations and want to make sure that the work hasn't already been done. Thanks. Zarar IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Configuring interceptors using annotations
Hi Zarar, It'd be great if you could file a feature request in JIRA for this though: http://issues.apache.org/jira/browse/CXF Thanks, - Dan On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote: Hi Zarar, As part of its JAXWS implementation CXF supports the @javax.jws.HandlerChain annotation for JAX-WS handlers. There are no custom annotations in CXF that allow to specify inbound/outbound fault/message interceptors (i.e. CXF handlers) .. Regards, Andrea. Zarar Siddiqi wrote: >Is there support for configuring interceptors using annotations? I'm looking >for something like the org.codehaus.xfire.annotations.InHandlers and >org.codehaus.xfire.annotations.OutHandlers class where were present in >XFire. > >I'm thinking of writing similar annotations and want to make sure that the >work hasn't already been done. > >Thanks. >Zarar > > IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: Configuring interceptors using annotations
Hi Dan, I've created the JIRA: http://issues.apache.org/jira/browse/CXF-803 Thanks, Zarar Dan Diephouse wrote: > > Hi Zarar, > It'd be great if you could file a feature request in JIRA for this though: > > http://issues.apache.org/jira/browse/CXF > > Thanks, > - Dan > > On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote: >> >> Hi Zarar, >> >> As part of its JAXWS implementation CXF supports the >> @javax.jws.HandlerChain annotation for JAX-WS handlers. >> There are no custom annotations in CXF that allow to specify >> inbound/outbound fault/message interceptors (i.e. CXF handlers) .. >> >> Regards, >> Andrea. >> >> Zarar Siddiqi wrote: >> >> >Is there support for configuring interceptors using annotations? I'm >> looking >> >for something like the org.codehaus.xfire.annotations.InHandlers and >> >org.codehaus.xfire.annotations.OutHandlers class where were present in >> >XFire. >> > >> >I'm thinking of writing similar annotations and want to make sure that >> the >> >work hasn't already been done. >> > >> >Thanks. >> >Zarar >> > >> > >> >> >> IONA Technologies PLC (registered in Ireland) >> Registered Number: 171387 >> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >> > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog > > -- View this message in context: http://www.nabble.com/Configuring-interceptors-using-annotations-tf4097300.html#a11659326 Sent from the cxf-user mailing list archive at Nabble.com.
Re: Configuring interceptors using annotations
Hi, I've submitted a patch for this JIRA, can someone help me review it and apply it if it is ok. Thanks Jeff Yu Zarar Siddiqi wrote: Hi Dan, I've created the JIRA: http://issues.apache.org/jira/browse/CXF-803 Thanks, Zarar Dan Diephouse wrote: Hi Zarar, It'd be great if you could file a feature request in JIRA for this though: http://issues.apache.org/jira/browse/CXF Thanks, - Dan On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote: Hi Zarar, As part of its JAXWS implementation CXF supports the @javax.jws.HandlerChain annotation for JAX-WS handlers. There are no custom annotations in CXF that allow to specify inbound/outbound fault/message interceptors (i.e. CXF handlers) .. Regards, Andrea. Zarar Siddiqi wrote: Is there support for configuring interceptors using annotations? I'm looking for something like the org.codehaus.xfire.annotations.InHandlers and org.codehaus.xfire.annotations.OutHandlers class where were present in XFire. I'm thinking of writing similar annotations and want to make sure that the work hasn't already been done. Thanks. Zarar IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: Configuring interceptors using annotations
Hi Jeff, Would you please re-upload this patch ensure that "Grant license to ASF for inclusion in ASF works" is selected? Thanks Freeman Jeff.Yu wrote: Hi, I've submitted a patch for this JIRA, can someone help me review it and apply it if it is ok. Thanks Jeff Yu Zarar Siddiqi wrote: Hi Dan, I've created the JIRA: http://issues.apache.org/jira/browse/CXF-803 Thanks, Zarar Dan Diephouse wrote: Hi Zarar, It'd be great if you could file a feature request in JIRA for this though: http://issues.apache.org/jira/browse/CXF Thanks, - Dan On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote: Hi Zarar, As part of its JAXWS implementation CXF supports the @javax.jws.HandlerChain annotation for JAX-WS handlers. There are no custom annotations in CXF that allow to specify inbound/outbound fault/message interceptors (i.e. CXF handlers) .. Regards, Andrea. Zarar Siddiqi wrote: Is there support for configuring interceptors using annotations? I'm looking for something like the org.codehaus.xfire.annotations.InHandlers and org.codehaus.xfire.annotations.OutHandlers class where were present in XFire. I'm thinking of writing similar annotations and want to make sure that the work hasn't already been done. Thanks. Zarar IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: Configuring interceptors using annotations
Hi, Freeman
Thanks, I've re-uploaded it.
Thanks
Jeff Yu
Freeman Fang wrote:
Hi Jeff,
Would you please re-upload this patch ensure that "Grant license to
ASF for inclusion in ASF works" is selected?
Thanks
Freeman
Jeff.Yu wrote:
Hi,
I've submitted a patch for this JIRA, can someone help me review it
and apply it if it is ok.
Thanks
Jeff Yu
Zarar Siddiqi wrote:
Hi Dan,
I've created the JIRA:
http://issues.apache.org/jira/browse/CXF-803
Thanks,
Zarar
Dan Diephouse wrote:
Hi Zarar,
It'd be great if you could file a feature request in JIRA for this
though:
http://issues.apache.org/jira/browse/CXF
Thanks,
- Dan
On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
Hi Zarar,
As part of its JAXWS implementation CXF supports the
@javax.jws.HandlerChain annotation for JAX-WS handlers.
There are no custom annotations in CXF that allow to specify
inbound/outbound fault/message interceptors (i.e. CXF handlers) ..
Regards,
Andrea.
Zarar Siddiqi wrote:
Is there support for configuring interceptors using annotations? I'm
looking
for something like the org.codehaus.xfire.annotations.InHandlers and
org.codehaus.xfire.annotations.OutHandlers class where were
present in
XFire.
I'm thinking of writing similar annotations and want to make sure
that
the
work hasn't already been done.
Thanks.
Zarar
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Configuring interceptors using annotations
Thanks Jeff I will take care of this patch Freeman Jeff.Yu wrote: Hi, Freeman Thanks, I've re-uploaded it. Thanks Jeff Yu Freeman Fang wrote: Hi Jeff, Would you please re-upload this patch ensure that "Grant license to ASF for inclusion in ASF works" is selected? Thanks Freeman Jeff.Yu wrote: Hi, I've submitted a patch for this JIRA, can someone help me review it and apply it if it is ok. Thanks Jeff Yu Zarar Siddiqi wrote: Hi Dan, I've created the JIRA: http://issues.apache.org/jira/browse/CXF-803 Thanks, Zarar Dan Diephouse wrote: Hi Zarar, It'd be great if you could file a feature request in JIRA for this though: http://issues.apache.org/jira/browse/CXF Thanks, - Dan On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote: Hi Zarar, As part of its JAXWS implementation CXF supports the @javax.jws.HandlerChain annotation for JAX-WS handlers. There are no custom annotations in CXF that allow to specify inbound/outbound fault/message interceptors (i.e. CXF handlers) .. Regards, Andrea. Zarar Siddiqi wrote: Is there support for configuring interceptors using annotations? I'm looking for something like the org.codehaus.xfire.annotations.InHandlers and org.codehaus.xfire.annotations.OutHandlers class where were present in XFire. I'm thinking of writing similar annotations and want to make sure that the work hasn't already been done. Thanks. Zarar IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: Configuring interceptors using annotations
Jeff, This is great... Another idea along a similar path if you need something to do would be to create a @Features annotation or something to do the same thing as the features stuff in the spring config. Dan On Wednesday 25 July 2007 02:50, Jeff.Yu wrote: > Hi, > > I've submitted a patch for this JIRA, can someone help me review it > and apply it if it is ok. > > Thanks > Jeff Yu > > Zarar Siddiqi wrote: > > Hi Dan, > > > > I've created the JIRA: > > > > http://issues.apache.org/jira/browse/CXF-803 > > > > Thanks, > > Zarar > > > > Dan Diephouse wrote: > >> Hi Zarar, > >> It'd be great if you could file a feature request in JIRA for this > >> though: > >> > >> http://issues.apache.org/jira/browse/CXF > >> > >> Thanks, > >> - Dan > >> > >> On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote: > >>> Hi Zarar, > >>> > >>> As part of its JAXWS implementation CXF supports the > >>> @javax.jws.HandlerChain annotation for JAX-WS handlers. > >>> There are no custom annotations in CXF that allow to specify > >>> inbound/outbound fault/message interceptors (i.e. CXF handlers) .. > >>> > >>> Regards, > >>> Andrea. > >>> > >>> Zarar Siddiqi wrote: > >>>> Is there support for configuring interceptors using annotations? > >>>> I'm > >>> > >>> looking > >>> > >>>> for something like the org.codehaus.xfire.annotations.InHandlers > >>>> and org.codehaus.xfire.annotations.OutHandlers class where were > >>>> present in XFire. > >>>> > >>>> I'm thinking of writing similar annotations and want to make sure > >>>> that > >>> > >>> the > >>> > >>>> work hasn't already been done. > >>>> > >>>> Thanks. > >>>> Zarar > >>> > >>> > >>> IONA Technologies PLC (registered in Ireland) > >>> Registered Number: 171387 > >>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, > >>> Ireland > >> > >> -- > >> Dan Diephouse > >> Envoi Solutions > >> http://envoisolutions.com | http://netzooid.com/blog -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Configuring interceptors using annotations
Hi, I've added the @Features annotation with the latest patch in this JIRA, can someone help me review and apply it if it is ok, also, in this patch, I've updated some codes according to the Glen's comments. Thanks Jeff Yu Daniel Kulp wrote: Jeff, This is great... Another idea along a similar path if you need something to do would be to create a @Features annotation or something to do the same thing as the features stuff in the spring config. Dan On Wednesday 25 July 2007 02:50, Jeff.Yu wrote: Hi, I've submitted a patch for this JIRA, can someone help me review it and apply it if it is ok. Thanks Jeff Yu Zarar Siddiqi wrote: Hi Dan, I've created the JIRA: http://issues.apache.org/jira/browse/CXF-803 Thanks, Zarar Dan Diephouse wrote: Hi Zarar, It'd be great if you could file a feature request in JIRA for this though: http://issues.apache.org/jira/browse/CXF Thanks, - Dan On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote: Hi Zarar, As part of its JAXWS implementation CXF supports the @javax.jws.HandlerChain annotation for JAX-WS handlers. There are no custom annotations in CXF that allow to specify inbound/outbound fault/message interceptors (i.e. CXF handlers) .. Regards, Andrea. Zarar Siddiqi wrote: Is there support for configuring interceptors using annotations? I'm looking for something like the org.codehaus.xfire.annotations.InHandlers and org.codehaus.xfire.annotations.OutHandlers class where were present in XFire. I'm thinking of writing similar annotations and want to make sure that the work hasn't already been done. Thanks. Zarar IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: Configuring interceptors using annotations
Jeff,
Thanks for the contribution.
One important note: your patch REALLY doesn't use the generics properly.
If you need to @SuppressWarnings("unchecked"), 75% of the time, you're
not doing something correctly. I've gone ahead and fixed up the code
in SVN. I encourage you to take a quick look. A good indication is
if you do something like "List a = new ArrayList()".All collections
should be typed in one form or another. (unless dealing with jdk1.4 code
like wsdl4j)
Dan
On Thursday 26 July 2007 03:57, Jeff.Yu wrote:
> Hi,
>
> I've added the @Features annotation with the latest patch in this
> JIRA, can someone help me review and apply it if it is ok, also, in
> this patch, I've updated some codes according to the Glen's comments.
>
> Thanks
> Jeff Yu
>
> Daniel Kulp wrote:
> > Jeff,
> >
> > This is great... Another idea along a similar path if you need
> > something to do would be to create a @Features annotation or
> > something to do the same thing as the features stuff in the spring
> > config.
> >
> > Dan
> >
> > On Wednesday 25 July 2007 02:50, Jeff.Yu wrote:
> >> Hi,
> >>
> >> I've submitted a patch for this JIRA, can someone help me review it
> >> and apply it if it is ok.
> >>
> >> Thanks
> >> Jeff Yu
> >>
> >> Zarar Siddiqi wrote:
> >>> Hi Dan,
> >>>
> >>> I've created the JIRA:
> >>>
> >>> http://issues.apache.org/jira/browse/CXF-803
> >>>
> >>> Thanks,
> >>> Zarar
> >>>
> >>> Dan Diephouse wrote:
> >>>> Hi Zarar,
> >>>> It'd be great if you could file a feature request in JIRA for
> >>>> this though:
> >>>>
> >>>> http://issues.apache.org/jira/browse/CXF
> >>>>
> >>>> Thanks,
> >>>> - Dan
> >>>>
> >>>> On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
> >>>>> Hi Zarar,
> >>>>>
> >>>>> As part of its JAXWS implementation CXF supports the
> >>>>> @javax.jws.HandlerChain annotation for JAX-WS handlers.
> >>>>> There are no custom annotations in CXF that allow to specify
> >>>>> inbound/outbound fault/message interceptors (i.e. CXF handlers)
> >>>>> ..
> >>>>>
> >>>>> Regards,
> >>>>> Andrea.
> >>>>>
> >>>>> Zarar Siddiqi wrote:
> >>>>>> Is there support for configuring interceptors using
> >>>>>> annotations? I'm
> >>>>>
> >>>>> looking
> >>>>>
> >>>>>> for something like the
> >>>>>> org.codehaus.xfire.annotations.InHandlers and
> >>>>>> org.codehaus.xfire.annotations.OutHandlers class where were
> >>>>>> present in XFire.
> >>>>>>
> >>>>>> I'm thinking of writing similar annotations and want to make
> >>>>>> sure that
> >>>>>
> >>>>> the
> >>>>>
> >>>>>> work hasn't already been done.
> >>>>>>
> >>>>>> Thanks.
> >>>>>> Zarar
> >>>>>
> >>>>>
> >>>>> IONA Technologies PLC (registered in Ireland)
> >>>>> Registered Number: 171387
> >>>>> Registered Address: The IONA Building, Shelbourne Road, Dublin
> >>>>> 4, Ireland
> >>>>
> >>>> --
> >>>> Dan Diephouse
> >>>> Envoi Solutions
> >>>> http://envoisolutions.com | http://netzooid.com/blog
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Configuring interceptors using annotations
Hi, Dan
Just review the changes that you made, it makes perfect sense. Thanks
-Jeff
Daniel Kulp wrote:
Jeff,
Thanks for the contribution.
One important note: your patch REALLY doesn't use the generics properly.
If you need to @SuppressWarnings("unchecked"), 75% of the time, you're
not doing something correctly. I've gone ahead and fixed up the code
in SVN. I encourage you to take a quick look. A good indication is
if you do something like "List a = new ArrayList()".All collections
should be typed in one form or another. (unless dealing with jdk1.4 code
like wsdl4j)
Dan
On Thursday 26 July 2007 03:57, Jeff.Yu wrote:
Hi,
I've added the @Features annotation with the latest patch in this
JIRA, can someone help me review and apply it if it is ok, also, in
this patch, I've updated some codes according to the Glen's comments.
Thanks
Jeff Yu
Daniel Kulp wrote:
Jeff,
This is great... Another idea along a similar path if you need
something to do would be to create a @Features annotation or
something to do the same thing as the features stuff in the spring
config.
Dan
On Wednesday 25 July 2007 02:50, Jeff.Yu wrote:
Hi,
I've submitted a patch for this JIRA, can someone help me review it
and apply it if it is ok.
Thanks
Jeff Yu
Zarar Siddiqi wrote:
Hi Dan,
I've created the JIRA:
http://issues.apache.org/jira/browse/CXF-803
Thanks,
Zarar
Dan Diephouse wrote:
Hi Zarar,
It'd be great if you could file a feature request in JIRA for
this though:
http://issues.apache.org/jira/browse/CXF
Thanks,
- Dan
On 7/17/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
Hi Zarar,
As part of its JAXWS implementation CXF supports the
@javax.jws.HandlerChain annotation for JAX-WS handlers.
There are no custom annotations in CXF that allow to specify
inbound/outbound fault/message interceptors (i.e. CXF handlers)
..
Regards,
Andrea.
Zarar Siddiqi wrote:
Is there support for configuring interceptors using
annotations? I'm
looking
for something like the
org.codehaus.xfire.annotations.InHandlers and
org.codehaus.xfire.annotations.OutHandlers class where were
present in XFire.
I'm thinking of writing similar annotations and want to make
sure that
the
work hasn't already been done.
Thanks.
Zarar
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin
4, Ireland
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
differences between Interceptors and Handlers
what is the differences between a CXF interceptor and a JAX-WS LogicalHandler (an implementation of javax.xml.ws.handler.LogicalHandler)??? I guess the functionality is the same, but the usage is different. Can I use an approach in which I have both a series of intercetpors (configured with Spring) and and Handler Chain defined in a handler-chain.xml file??? Thanks Davide -- View this message in context: http://www.nabble.com/differences-between-Interceptors-and-Handlers-tf4883199.html#a13975552 Sent from the cxf-user mailing list archive at Nabble.com.
Re: Message.getContent(???) options for interceptors
Glen, It REALLY depends on where in the interceptor chain you are and what interceptors are in the chain and have already run. For example, on the server side incoming, the ONLY thing that the transports put in the contents is the InputStream. Thus, for the first interceptor in the chain, the only content that will be there is that InputStream. As the interceptors execute, they add content types, possibly remove content types, manipulate them, etc... to do their job. For example: for soap/xml cases, one of the first interceptors in the chain will be the StaxInInterceptor. It takes that output stream and wrappers it with an XmlStreamReader and adds that to the content. Thus, stuff that runs after the StaxInInterceptor will have the InputStream if they need it (although be careful as Stax buffers things), as well as the XmlStreamReader. The SAAJInInterceptor takes the reader and builds an SAAJ object.Thus, any interceptors after that interceptor can getContent(SOAPMessage.class). Eventually, the subclasses of AbstractInDatabindingInterceptor will add a "List" thing to the contents which is the list of JAXB objects (if using jaxb) to the contents. There really isn't a list of possible classes as it's completely dynamic. Different interceptors can produce/consume different things depending on the context. For example, if using a "provider" based service, there wouldn't be the databinding things at all.If using CORBA, there won't be an InputStream/OutputStream as they don't make sense for CORBA. Likewise, for JMS, if it's a text message, we could put a StringReader/StringWriter in there instead of an OutputStream/IntputStream as an optimization (we don't right now, but it would be good to do). One thing I would suggest is put a breakpoint in the PhaseInterceptorChain at the call to currentInterceptor.handleMessage(message) and printout the contents before and after each interceptor. You can kind of see how the interceptors manipulate the message as they do their work. That actually may be a good start for a tutorial. You COULD write a "generic" interceptor that just prints the different content types in the message and maybe the properties of the message. Run it in one phase, see the result. Move it to another phase, see what is different. Put it before/after the StaxInInterceptor, see what happens. Etc... Dan On Monday 28 January 2008, Glen Mazza wrote: > I have a question about the > org.apache.cxf.message.Message.getContent(?) method within > interceptors. > > The CXF sample interceptor[1] on line 49 has this call to get the > content (payload) of the SOAP message: > > OutputStream os = message.getContent(OutputStream.class); > > Question: Besides "OutputStream.class", what other options do I have > as the argument to getContent() for a message that comes from an > interceptor's handleMessage(Message m) or handleFault(Message m)? > > (Also, does anyone know where in the CXF source code that list of > acceptable classes is defined? Understanding the source may help me > here.) > > Thanks, > Glen > > [1] http://tinyurl.com/yqz58p -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Interceptors pulling values out of requests
Hello, I'm writing a webservice with Aegis Bindings and would like to write an interceptor to collect certain information - eg I want to look for specific values in the incoming XML (the paramter values to the functions in the SEI) - though I have followed some of the examples we can't quite get at what we need. Has anyone tried this before? What is the best phase to use to get this info? What objects can I grab and traverse to get me what I need? Thanks!
RE: differences between Interceptors and Handlers
CXF interceptor API is the core of CXF runtime to process message flows, internally JAX-WS handlers are implemented as CXF interceptors. If you want to stick to the spec, you would avoid using CXF interceptors directly if possible. However there are circumstances that CXF interceptors give you more flexibility and better performance. One concrete example is writing a security interceptor to check the permission based on information in soap headers, this can be done using JAX-WS SOAP handlers or using CXF interceptors. Most CXF interceptors are STAX based designed to achieve smaller footprint, but JAX-WS handlers (eg, SOAP handlers) require creating DOM tree in the memory which definitely has impact on the performance. Cheers, Jervis > -Original Message- > From: Davide Gesino [mailto:[EMAIL PROTECTED] > Sent: 2007年11月28日 1:25 > To: cxf-user@incubator.apache.org > Subject: differences between Interceptors and Handlers > > > what is the differences between a CXF interceptor and a JAX-WS > LogicalHandler > (an implementation of javax.xml.ws.handler.LogicalHandler)??? > I guess the functionality is the same, but the usage is different. > Can I use an approach in which I have both a series of intercetpors > (configured with Spring) and and Handler Chain defined in a > handler-chain.xml file??? > > Thanks > > Davide > -- > View this message in context: > http://www.nabble.com/differences-between-Interceptors-and-Handlers-tf > 4883199.html#a13975552 > Sent from the cxf-user mailing list archive at Nabble.com. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
mutithread issues in interceptors and endpoints
Hi, a question about multithread issues in CXF (maybe a silly one). Multiple requests are managed relying upon the servlet engine I CXF uses. Every request (so every SOAPMessageContext) lives in his own thread? If there is a pool of them, every thread in the pool manages one request each time? In CXF there is a single instance of any endpoint bean that manages all the incoming requests, or somehow there is way to have a pool of endpoints? There is also a single interceptor chain for all of them? So when I program my own interceptor what are the multithread issued I have to face and consider? -- View this message in context: http://www.nabble.com/mutithread-issues-in-interceptors-and-endpoints-tp15611836p15611836.html Sent from the cxf-user mailing list archive at Nabble.com.
Programatically installing interceptors per (Bus|Service|Endpoint)
I understand that CXF provides APIs for installed interceptors through the InterceptorProvider interface, which the Bus, Endpoint, and Service types all extend (among other types). Suppose I want to create, via configuration, some sort of CXF plugin (I hesitate to call this an interceptor, for reasons which should become obvious). The purpose of this plugin is to install interceptors programatically into the call chain. I can see how to do this using a reference to a Bus -- e.g., I can spring-load the plugin I want to install, and wire it up to the Bus -- common pattern. And from there, I can get access to the Bus-level InterceptorProvider, since the Bus extends that type. That would work in the case where I want my plugin to install these interceptors globally, i.e, for all services and endpoints in a Bus; however, suppose I want to install my interceptors at a finer level of granularity, e.g., per endpoint. Is there a way for my plugin, which seems to be loaded at Bus initialization time, to get a handle on the Service or Endpoint (which also implement InterceptorProvider) for which it is (or counterfactually would be) configured? Is this an envisioned pattern? Or is there some other sort of interceptor I don't know of, e.g, which hooks into Service or Endpoint creation? Thanks! -Fred
RE: Interceptors pulling values out of requests
I just updated the wiki page [1], hopefully it is more clear now how to write
and configure user interceptors. Please let me know if there is anything
missing or still not clear on this page. I am not sure what type of parameters
you want to access through interceptors, lets presume you want to access the
java parameter objects that are used to invoke the SEI operations. For example,
for an operation whose signature is "String sayHi(String input)", you may want
to access the value of input before sayHi is invoked. In this case, basically
what you need to do is:
1. Write an interceptor according to the instruction [1].
2. The java parameter objects are only available after a certain interceptor.
To figure out exactly what phase your interceptor need to sit in, you need to
understand what happens along the interceptor chain. Basically when the request
comes in, it is available as an InputStream, then a StaxReader is created in
StaxInInterceptor to read this InputStream. The flow in the interceptor chain
keeps moving. If the incoming request is a soap message, the soap headers will
be stripped off by some intercetors, then the soap body. The content of soap
body will be marshaled into java objects by either JAXB data binding or Aegis
data binding by data binding interceptors. Finally the
ServiceInvokerInterceptor is invoked which will in turn dispatch the request to
"sayHi".
In your case, I believe adding your interceptor before
ServiceInvokerInterceptor should do the trick.
3. The java parameter objects can be accessed from Message. Eg:
public class MyInterceptor extends AbstractPhaseInterceptor {
public MyInterceptor () {
super(Phase.INVOKE);
}
public void handleMessage(final Message message) {
Object invokee = message.getContent(List.class);
if (invokee == null) {
invokee = message.getContent(Object.class);
}
.
}
}
To understand more about CXF interceptor chain, I would suggest you do a quick
debugging to see how the message flows along the interceptor chain.
[1]. http://cwiki.apache.org/confluence/display/CXF20DOC/Interceptors
Cheers,
Jervis
> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月20日 3:55
> To: cxf-user@incubator.apache.org
> Subject: Interceptors pulling values out of requests
>
> Hello,
>
> I'm writing a webservice with Aegis Bindings and would like to write an
> interceptor to collect certain information - eg I want to look for
> specific values in the incoming XML (the paramter values to the
> functions in the SEI) - though I have followed some of the examples we
> can't quite get at what we need.
>
> Has anyone tried this before?
>
> What is the best phase to use to get this info?
>
> What objects can I grab and traverse to get me what I need?
>
> Thanks!
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Interceptors pulling values out of requests
Thank you for the information. It isn't quite solving my issue though.
What I am trying to do is to log the values in my request stream. My request
looks like this:
http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
123
ABC123DEF456
1
The inputs are a custom session class I created, and a long
I want my interceptor to get out
-The name of the service
-The name of the method
-The session as an object
-The channel id as an object
I want to be able to do this all in one interceptor, and I do not want to make
it a high
Impact operation as it would be done in every call and written to a log. I
tried your example and the body comes through as null always.
I have been doing this:
List body = msg.getContent(List.class);
mySession sess = (mySession)body.get(0);
Which is not ideal.
I would like to access the input generically - in so much that I want to pull
named parameters from a variety of different calls (some called channelId, some
userId, etc) and I am looking to be able to either sniff for these items
trivially (they are not always in there) if possible. There will always be a
mySession type object that has two fields in it, but I don't know if it will
always be first.
So, with this in mind, can you provide more guidence. I am doing this
currently in the invoke phase.
Thanks!
-Tony
-Original Message-
From: Liu, Jervis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 20, 2007 12:36 AM
To: cxf-user@incubator.apache.org
Subject: RE: Interceptors pulling values out of requests
I just updated the wiki page [1], hopefully it is more clear now how to write
and configure user interceptors. Please let me know if there is anything
missing or still not clear on this page. I am not sure what type of parameters
you want to access through interceptors, lets presume you want to access the
java parameter objects that are used to invoke the SEI operations. For example,
for an operation whose signature is "String sayHi(String input)", you may want
to access the value of input before sayHi is invoked. In this case, basically
what you need to do is:
1. Write an interceptor according to the instruction [1].
2. The java parameter objects are only available after a certain interceptor.
To figure out exactly what phase your interceptor need to sit in, you need to
understand what happens along the interceptor chain. Basically when the request
comes in, it is available as an InputStream, then a StaxReader is created in
StaxInInterceptor to read this InputStream. The flow in the interceptor chain
keeps moving. If the incoming request is a soap message, the soap headers will
be stripped off by some intercetors, then the soap body. The content of soap
body will be marshaled into java objects by either JAXB data binding or Aegis
data binding by data binding interceptors. Finally the
ServiceInvokerInterceptor is invoked which will in turn dispatch the request to
"sayHi".
In your case, I believe adding your interceptor before
ServiceInvokerInterceptor should do the trick.
3. The java parameter objects can be accessed from Message. Eg:
public class MyInterceptor extends AbstractPhaseInterceptor {
public MyInterceptor () {
super(Phase.INVOKE);
}
public void handleMessage(final Message message) {
Object invokee = message.getContent(List.class);
if (invokee == null) {
invokee = message.getContent(Object.class);
}
.
}
}
To understand more about CXF interceptor chain, I would suggest you do a quick
debugging to see how the message flows along the interceptor chain.
[1]. http://cwiki.apache.org/confluence/display/CXF20DOC/Interceptors
Cheers,
Jervis
> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月20日 3:55
> To: cxf-user@incubator.apache.org
> Subject: Interceptors pulling values out of requests
>
> Hello,
>
> I'm writing a webservice with Aegis Bindings and would like to write an
> interceptor to collect certain information - eg I want to look for
> specific values in the incoming XML (the paramter values to the
> functions in the SEI) - though I have followed some of the examples we
> can't quite get at what we need.
>
> Has anyone tried this before?
>
> What is the best phase to use to get this info?
>
> What objects can I grab and traverse to get me what I need?
>
> Thanks!
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Interceptors pulling values out of requests
Am Dienstag, den 20.11.2007, 00:36 -0500 schrieb Liu, Jervis: > I just updated the wiki page [1], hopefully it is more clear now how > to write and configure user interceptors. Please let me know if there > is anything missing or still not clear on this page. In the "Adding interceptors through configuration" section, we need to know what those configuration files should be named and where they should be placed. Or, if that is already documented someplace else, a link given to where that is documented. Regards, Glen > [1]. http://cwiki.apache.org/confluence/display/CXF20DOC/Interceptors > > Cheers, > Jervis >
RE: Interceptors pulling values out of requests
What does your SEI operation look like? Sth like "void getChannel(Session s,
long channelD)" ? This should work. The List object you get by using "List body
= msg.getContent(List.class)" contains Session object and the channelD, they
are ordered, i.e., body.get(0) always return the Session object and body.get(1)
returns whatever the second parameter of is.
If it does not work, most likely it is because you did not put your interceptor
at the right position: when your interceptor is invoked, the List has not been
populated yet. You may want to have a quick debug to see if your interceptor is
invoked right before ServiceInvokerInterceptor.
BTW, you get can method name using following code (take a look at
org.apache.cxf.interceptor. ServiceInvokerInterceptor and
org.apache.cxf.service.invoker. AbstractInvoker)
public class MyInterceptor extends AbstractPhaseInterceptor {
public MyInterceptor () {
super(Phase.INVOKE);
addBefore(ServiceInvokerInterceptor.class.getName());
}
public void handleMessage(final Message message) {
final Exchange exchange = message.getExchange();
BindingOperationInfo bop = exchange.get(BindingOperationInfo.class);
MethodDispatcher md = (MethodDispatcher)
exchange.get(Service.class).get(MethodDispatcher.class.getName());
Method m = md.getMethod(bop);
.
}
}
Hope this helps,
Jervis
> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月21日 0:41
> To: cxf-user@incubator.apache.org; Liu, Jervis
> Subject: RE: Interceptors pulling values out of requests
>
>
> Thank you for the information. It isn't quite solving my issue though.
>
> What I am trying to do is to log the values in my request stream. My
> request looks like this:
>
>
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
>
>
> 123
> ABC123DEF456
>
> 1
>
>
>
>
>
> The inputs are a custom session class I created, and a long
>
> I want my interceptor to get out
>
> -The name of the service
> -The name of the method
> -The session as an object
> -The channel id as an object
>
> I want to be able to do this all in one interceptor, and I do not want to make
> it a high
> Impact operation as it would be done in every call and written to a log. I
> tried your example and the body comes through as null always.
>
> I have been doing this:
>
> List body = msg.getContent(List.class);
> mySession sess = (mySession)body.get(0);
>
>
> Which is not ideal.
>
> I would like to access the input generically - in so much that I want to pull
> named parameters from a variety of different calls (some called channelId,
> some userId, etc) and I am looking to be able to either sniff for these items
> trivially (they are not always in there) if possible. There will always be a
> mySession type object that has two fields in it, but I don't know if it will
> always be first.
>
> So, with this in mind, can you provide more guidence. I am doing this
> currently in the invoke phase.
>
> Thanks!
>
> -Tony
>
> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 20, 2007 12:36 AM
> To: cxf-user@incubator.apache.org
> Subject: RE: Interceptors pulling values out of requests
>
> I just updated the wiki page [1], hopefully it is more clear now how to write
> and configure user interceptors. Please let me know if there is anything
> missing or still not clear on this page. I am not sure what type of parameters
> you want to access through interceptors, lets presume you want to access
> the java parameter objects that are used to invoke the SEI operations. For
> example, for an operation whose signature is "String sayHi(String input)",
> you may want to access the value of input before sayHi is invoked. In this
> case, basically what you need to do is:
>
> 1. Write an interceptor according to the instruction [1].
>
> 2. The java parameter objects are only available after a certain interceptor.
> To figure out exactly what phase your interceptor need to sit in, you need to
> understand what happens along the interceptor chain. Basically when the
> request comes in, it is available as an InputStream, then a StaxReader is
> created in StaxInInterceptor to read this InputStream. The flow in the
> interceptor chain keeps moving. If the incoming request is a soap message,
> the soap headers will be stripped off by some intercetors, then the soap
> body. The content of soap body will be marshaled into java objects by either
> JAXB data bin
RE: Interceptors pulling values out of requests
This has nudged me along, thanks. =)
The only question I have remaining is, is there a way to get a list at any
point that actually has the paramter names? Basically a map. Ideally I would
like to be able to, for any present or future function call, to get the named
paramters so I could drop those directly into the log.
Thanks for your help!
-Tony
-Original Message-
From: Liu, Jervis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 20, 2007 10:00 PM
To: Vespa, Anthony J; cxf-user@incubator.apache.org
Subject: RE: Interceptors pulling values out of requests
What does your SEI operation look like? Sth like "void getChannel(Session s,
long channelD)" ? This should work. The List object you get by using "List body
= msg.getContent(List.class)" contains Session object and the channelD, they
are ordered, i.e., body.get(0) always return the Session object and body.get(1)
returns whatever the second parameter of is.
If it does not work, most likely it is because you did not put your interceptor
at the right position: when your interceptor is invoked, the List has not been
populated yet. You may want to have a quick debug to see if your interceptor is
invoked right before ServiceInvokerInterceptor.
BTW, you get can method name using following code (take a look at
org.apache.cxf.interceptor. ServiceInvokerInterceptor and
org.apache.cxf.service.invoker. AbstractInvoker)
public class MyInterceptor extends AbstractPhaseInterceptor {
public MyInterceptor () {
super(Phase.INVOKE);
addBefore(ServiceInvokerInterceptor.class.getName());
}
public void handleMessage(final Message message) {
final Exchange exchange = message.getExchange();
BindingOperationInfo bop = exchange.get(BindingOperationInfo.class);
MethodDispatcher md = (MethodDispatcher)
exchange.get(Service.class).get(MethodDispatcher.class.getName());
Method m = md.getMethod(bop);
.
}
}
Hope this helps,
Jervis
> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月21日 0:41
> To: cxf-user@incubator.apache.org; Liu, Jervis
> Subject: RE: Interceptors pulling values out of requests
>
>
> Thank you for the information. It isn't quite solving my issue though.
>
> What I am trying to do is to log the values in my request stream. My
> request looks like this:
>
>
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
>
>
> 123
> ABC123DEF456
>
> 1
>
>
>
>
>
> The inputs are a custom session class I created, and a long
>
> I want my interceptor to get out
>
> -The name of the service
> -The name of the method
> -The session as an object
> -The channel id as an object
>
> I want to be able to do this all in one interceptor, and I do not want to make
> it a high
> Impact operation as it would be done in every call and written to a log. I
> tried your example and the body comes through as null always.
>
> I have been doing this:
>
> List body = msg.getContent(List.class);
> mySession sess = (mySession)body.get(0);
>
>
> Which is not ideal.
>
> I would like to access the input generically - in so much that I want to pull
> named parameters from a variety of different calls (some called channelId,
> some userId, etc) and I am looking to be able to either sniff for these items
> trivially (they are not always in there) if possible. There will always be a
> mySession type object that has two fields in it, but I don't know if it will
> always be first.
>
> So, with this in mind, can you provide more guidence. I am doing this
> currently in the invoke phase.
>
> Thanks!
>
> -Tony
>
> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 20, 2007 12:36 AM
> To: cxf-user@incubator.apache.org
> Subject: RE: Interceptors pulling values out of requests
>
> I just updated the wiki page [1], hopefully it is more clear now how to write
> and configure user interceptors. Please let me know if there is anything
> missing or still not clear on this page. I am not sure what type of parameters
> you want to access through interceptors, lets presume you want to access
> the java parameter objects that are used to invoke the SEI operations. For
> example, for an operation whose signature is "String sayHi(String input)",
> you may want to access the value of input before sayHi is invoked. In this
> case, basically what you need to do is:
>
> 1. Write an interceptor according to the instruction [1].
>
> 2. The java parameter objects are only available after a certain interceptor.
&g
RE: Interceptors pulling values out of requests
Did you really mean the names of parameters or what you want to get is instead
the value of incoming parameters? If it is the later, I would say it is only
possible to get the parameter values after the data binding marshaling stage.
The exact point various depending on the protocol binding (eg, SOAP binding or
XML binding etc) and data binding being used. The safest bet to make is before
the ServiceInvokerInterceptor. If it is the former, normally a list of
parameter names is available as soon as the name of the method to invoke has
been determined, as you can always get parameter names using reflection from
the Method object. Unfortunately to know exactly when this happens is more
complex than knowing parameter values. If you do a search for
"put(BindingOperationInfo.class" throughout the CXF workspace, you may find
what interceptors are responsible for determining which method to dispatch to
based on different criteria (eg, RPC or Doc lit wrapped or REST HTTP binding..).
Cheers,
Jervis
> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月21日 22:19
> To: Liu, Jervis; cxf-user@incubator.apache.org
> Subject: RE: Interceptors pulling values out of requests
>
> This has nudged me along, thanks. =)
>
> The only question I have remaining is, is there a way to get a list at any
> point
> that actually has the paramter names? Basically a map. Ideally I would
> like to be able to, for any present or future function call, to get the named
> paramters so I could drop those directly into the log.
>
> Thanks for your help!
>
> -Tony
>
> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 20, 2007 10:00 PM
> To: Vespa, Anthony J; cxf-user@incubator.apache.org
> Subject: RE: Interceptors pulling values out of requests
>
> What does your SEI operation look like? Sth like "void getChannel(Session s,
> long channelD)" ? This should work. The List object you get by using "List
> body = msg.getContent(List.class)" contains Session object and the channelD,
> they are ordered, i.e., body.get(0) always return the Session object and
> body.get(1) returns whatever the second parameter of is.
>
> If it does not work, most likely it is because you did not put your
> interceptor
> at the right position: when your interceptor is invoked, the List has not been
> populated yet. You may want to have a quick debug to see if your
> interceptor is invoked right before ServiceInvokerInterceptor.
>
> BTW, you get can method name using following code (take a look at
> org.apache.cxf.interceptor. ServiceInvokerInterceptor and
> org.apache.cxf.service.invoker. AbstractInvoker)
>
> public class MyInterceptor extends AbstractPhaseInterceptor {
> public MyInterceptor () {
> super(Phase.INVOKE);
> addBefore(ServiceInvokerInterceptor.class.getName());
> }
>
> public void handleMessage(final Message message) {
> final Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.get(BindingOperationInfo.class);
> MethodDispatcher md = (MethodDispatcher)
> exchange.get(Service.class).get(MethodDispatcher.class.getName());
> Method m = md.getMethod(bop);
> .
> }
>
> }
>
> Hope this helps,
> Jervis
>
>
> > -Original Message-
> > From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> > Sent: 2007年11月21日 0:41
> > To: cxf-user@incubator.apache.org; Liu, Jervis
> > Subject: RE: Interceptors pulling values out of requests
> >
> >
> > Thank you for the information. It isn't quite solving my issue though.
> >
> > What I am trying to do is to log the values in my request stream. My
> > request looks like this:
> >
> >
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> >
> >
> >
> > 123
> > ABC123DEF456
> >
> > 1
> >
> >
> >
> >
> >
> > The inputs are a custom session class I created, and a long
> >
> > I want my interceptor to get out
> >
> > -The name of the service
> > -The name of the method
> > -The session as an object
> > -The channel id as an object
> >
> > I want to be able to do this all in one interceptor, and I do not want to
> make
> > it a high
> > Impact operation as it would be done in every call and written to a log. I
> > tried your example and the body comes through as null always.
> >
> > I have been doing this:
&g
Dynamically change interceptors in an interceptor chain?
Hello, Can I program an interceptor in a web service's incoming interceptor chain to dynamically route to another interceptor other than the one predefined in its chain (and ignore all subsequent interceptors in the predefined chain)? In other words, for an interceptor chain A->B->C->D, can I add business logic in interceptor A for it to route to A->E->F->G instead? In particular, I would like to avoid it doing A->E->F->G->B->C->D if I can, i.e., once I reroute, I don't want it to return to the other interceptors in the predefined chain. Thanks, Glen -- View this message in context: http://www.nabble.com/Dynamically-change-interceptors-in-an-interceptor-chain--tp15546687p15546687.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: mutithread issues in interceptors and endpoints
On Thursday 21 February 2008, Davide Gesino wrote: > a question about multithread issues in CXF (maybe a silly one). > Multiple requests are managed relying upon the servlet engine I CXF > uses. Every request (so every SOAPMessageContext) lives in his own > thread? If there is a pool of them, every thread in the pool manages > one request each time? Yea. Pretty much. As a request comes in, the servlet engine (or jetty if using the embedded stuff) picks a thread and starts dispatching the request on it. > In CXF there is a single instance of any endpoint bean that manages > all the incoming requests, or somehow there is way to have a pool of > endpoints? With a little bit of code, yes. You can can configure in your own invoker that does something diffent. If you look in org.apache.cxf.jaxws.JAXWSMethodInvoker and it's super classes, there are various ways to configure other policies. The simplest way would be to just subclass it and overwride the getServiceObject and releaseServiceObject methods to do whatever you need them to do. Those methods would be called for each invokation, but they could return an instance from a pool, create a new one for each invoke, etc... There was also this message that mentioned something about spring support for per-session or similar things: http://www.nabble.com/Re:-Share-object-in-request-scope-on-ws-server-p14674619.html I've never tried that though. > There is also a single interceptor chain for all of them? Yes and no. A new interceptor chain is created (cloned actually) for each request. Thus, the chain itself can be modified during the execution of the message without impacting future requests. However, the interceptor instances are not cloned. A single instance is used for all requests. > So when I program my own interceptor what are the multithread issued I > have to face and consider? Well, it needs to be threadsafe/reentrant. :-) Seriously, if you need to pass values to other interceptors along the same chain, etc... you should store them in the Message or in the exchange. (msg.getExchange()). If you need to hold some state for a session, grab the HttpRequest from the msg and create an http session. Any instance variables would need to be properly protected as they would apply for all invokations of that endpoint. (example: use an AtomicInteger for a "hit count" type thing) -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: mutithread issues in interceptors and endpoints
Thanks a lot! I have a few more questions about it...
>
>
>> In CXF there is a single instance of any endpoint bean that manages
>> all the incoming requests, or somehow there is way to have a pool of
>> endpoints?
>>
>
> With a little bit of code, yes. You can can configure in your own
> invoker that does something diffent. If you look in
> org.apache.cxf.jaxws.JAXWSMethodInvoker and it's super classes, there
> are various ways to configure other policies. The simplest way would
> be to just subclass it and overwride the getServiceObject and
> releaseServiceObject methods to do whatever you need them to do.
> Those methods would be called for each invokation, but they could return
> an instance from a pool, create a new one for each invoke, etc...
>
For the endpoint invocation the defauls is
org.apache.cxf.jaxws.JAXWSMethodInvoker that inherit from FactoryInvoker. So
each time I call a remote method a new endpoint instance is created?
To use a single instance should I have to use BeanInvoker?
> Seriously, if you need to pass values to other interceptors along the
> same chain, etc... you should store them in the Message or in the
> exchange. (msg.getExchange()). If you need to hold some state for a
> session, grab the HttpRequest from the msg and create an http session.
> Any instance variables would need to be properly protected as they would
> apply for all invokations of that endpoint. (example: use an
> AtomicInteger for a "hit count" type thing)
>
considering JAX-WS handler instead of interceptor is the same thing?
The safe place where to store request variables in a handler is the context
itself(and access them injecting the Web ServiceContext in the endpoint) ??
something similar to:
public boolean handleMessage(SOAPMessageContext ctx) {
ctx.put("KEY","VALUE");
...
--
View this message in context:
http://www.nabble.com/mutithread-issues-in-interceptors-and-endpoints-tp15611836p15633391.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: mutithread issues in interceptors and endpoints
On Friday 22 February 2008, Davide Gesino wrote:
> >> In CXF there is a single instance of any endpoint bean that
> >> manages all the incoming requests, or somehow there is way to have
> >> a pool of endpoints?
> >
> > With a little bit of code, yes. You can can configure in your own
> > invoker that does something diffent. If you look in
> > org.apache.cxf.jaxws.JAXWSMethodInvoker and it's super classes,
> > there are various ways to configure other policies. The simplest
> > way would be to just subclass it and overwride the getServiceObject
> > and releaseServiceObject methods to do whatever you need them to do.
> > Those methods would be called for each invokation, but they could
> > return an instance from a pool, create a new one for each invoke,
> > etc...
>
> For the endpoint invocation the defauls is
> org.apache.cxf.jaxws.JAXWSMethodInvoker that inherit from
> FactoryInvoker. So each time I call a remote method a new endpoint
> instance is created? To use a single instance should I have to use
> BeanInvoker?
No, the default is actually single instance. If you look in the
JAXWSMethodInvoker constructor, the default is to create a Factory that
just returns the single instance. Thus, you have to go out of your way
to not have that behavior.
Looking at the code (this seems to be some code that came from XFire),
there is some ScopePolicy things that seem to do various things, but
they seem to be very confusing and also won't work with the
JAXWSMethodInvoker anyway due to that singleton factory thing.
There's PROBABLY a way to use the
org.apache.cxf.service.invoker.LocalFactory with a RequestScopePolicy
thing to have it create a new instance of each request. Maybe. I'm
not really sure if any of that is working and it's all very confusing.
I'm tempted to rip that all out and just have a couple different
factories. (SingleInstanceFactory, PerRequestFactory, SessionFactory,
PooledFactory, etc...)
That all said, it's probably just easier to subclass the
JAXWSMethodInvoker and overwride the getServiceObject and
releaseServiceObject methods to do what you need. Ideally, the
factorys could do that, but that seems very complicated right now (and
the factories aren't hooked into the release stuff at all, which isn't
good).
> > Seriously, if you need to pass values to other interceptors along
> > the same chain, etc... you should store them in the Message or in
> > the exchange. (msg.getExchange()). If you need to hold some
> > state for a session, grab the HttpRequest from the msg and create an
> > http session. Any instance variables would need to be properly
> > protected as they would apply for all invokations of that endpoint.
> > (example: use an AtomicInteger for a "hit count" type thing)
>
> considering JAX-WS handler instead of interceptor is the same thing?
> The safe place where to store request variables in a handler is the
> context itself(and access them injecting the Web ServiceContext in the
> endpoint) ?? something similar to:
>
> public boolean handleMessage(SOAPMessageContext ctx) {
>
> ctx.put("KEY","VALUE");
> ...
Yep. However, with JAX-WS handlers, you would need to set the Scope as
well: ctx.setScope("KEY", Scope.APPLICATION)
The default in handlers is Handler scope. Thus, those values will be
available to other handlers, but not to the application code.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: mutithread issues in interceptors and endpoints
Daniel Kulp wrote: In CXF there is a single instance of any endpoint bean that manages all the incoming requests, or somehow there is way to have a pool of endpoints? With a little bit of code, yes. You can can configure in your own invoker that does something diffent. If you look in org.apache.cxf.jaxws.JAXWSMethodInvoker and it's super classes, there are various ways to configure other policies. The simplest way would be to just subclass it and overwride the getServiceObject and releaseServiceObject methods to do whatever you need them to do. Those methods would be called for each invokation, but they could return an instance from a pool, create a new one for each invoke, etc... You could probably do pooling via Spring AOP. I haven't tested this config but based on the docs the following should work (assuming you include the right library JARs). See the Spring JavaDocs for CommonsPoolTargetSource for details of how to control the pool properties: ... -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: mutithread issues in interceptors and endpoints
> Looking at the code (this seems to be some code that came from XFire),
> there is some ScopePolicy things that seem to do various things, but
> they seem to be very confusing and also won't work with the
> JAXWSMethodInvoker anyway due to that singleton factory thing.
> There's PROBABLY a way to use the
> org.apache.cxf.service.invoker.LocalFactory with a RequestScopePolicy
> thing to have it create a new instance of each request. Maybe. I'm
> not really sure if any of that is working and it's all very confusing.
> I'm tempted to rip that all out and just have a couple different
> factories. (SingleInstanceFactory, PerRequestFactory, SessionFactory,
> PooledFactory, etc...)
>
I have tried the following code, and actually it works fine, it creates a
new endpoint bean instance for each request.
ScopePolicy policy = RequestScopePolicy.instance();
org.apache.cxf.common.util.factory.Factory factory = new
LocalFactory(GreeterImpl.class);
JAXWSMethodInvoker invoker = new JAXWSMethodInvoker(fattorazza, policy);
JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
factoryBean.setAddress(address);
factoryBean.setServiceBean(implementor);
factoryBean.setInvoker(invoker);
factoryBean.create();
Endpoint.publish(address, implementor);
Just a note on the RequestScopePolicy: it seem to be a singleton, but the
constructor is not private, so the singletor factory can be violated, here
is the code.
public class RequestScopePolicy implements ScopePolicy {
private static final RequestScopePolicy SINGLETON = new
RequestScopePolicy();
public Factory applyScope(Factory f, Exchange ex) {
return f;
}
public static ScopePolicy instance() {
return SINGLETON;
}
}
--
View this message in context:
http://www.nabble.com/mutithread-issues-in-interceptors-and-endpoints-tp15611836p15707562.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
Hi Fred, Not sure if I understand your question correctly. If what you want is to instantiate and install interceptors per service/endpoint/binding, for example, you may have a strategy that can load different interceptors depending on a specific binding property, yes surely you can do this. SoapBindingFactory.java shows how SOAP binding specific interceptors are loaded. Cheers, Jervis > -Original Message- > From: Fred Dushin [mailto:[EMAIL PROTECTED] > Sent: 2007?3?21? 5:02 > To: cxf-user@incubator.apache.org; cxf-dev@incubator.apache.org > Subject: Programatically installing interceptors per > (Bus|Service|Endpoint) > > > I understand that CXF provides APIs for installed interceptors > through the InterceptorProvider interface, which the Bus, Endpoint, > and Service types all extend (among other types). > > Suppose I want to create, via configuration, some sort of CXF plugin > (I hesitate to call this an interceptor, for reasons which should > become obvious). The purpose of this plugin is to install > interceptors programatically into the call chain. > > I can see how to do this using a reference to a Bus -- e.g., I can > spring-load the plugin I want to install, and wire it up to the Bus > -- common pattern. And from there, I can get access to the > Bus-level > InterceptorProvider, since the Bus extends that type. > > That would work in the case where I want my plugin to install these > interceptors globally, i.e, for all services and endpoints in > a Bus; > however, suppose I want to install my interceptors at a finer level > of granularity, e.g., per endpoint. Is there a way for my plugin, > which seems to be loaded at Bus initialization time, to get a handle > on the Service or Endpoint (which also implement > InterceptorProvider) > for which it is (or counterfactually would be) configured? Is this > an envisioned pattern? Or is there some other sort of interceptor I > don't know of, e.g, which hooks into Service or Endpoint creation? > > Thanks! > -Fred >
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Fred Dushin wrote:
I understand that CXF provides APIs for installed interceptors
through the InterceptorProvider interface, which the Bus, Endpoint,
and Service types all extend (among other types).
Suppose I want to create, via configuration, some sort of CXF plugin
(I hesitate to call this an interceptor, for reasons which should
become obvious). The purpose of this plugin is to install
interceptors programatically into the call chain.
I can see how to do this using a reference to a Bus -- e.g., I can
spring-load the plugin I want to install, and wire it up to the Bus
-- common pattern. And from there, I can get access to the Bus-level
InterceptorProvider, since the Bus extends that type.
That would work in the case where I want my plugin to install these
interceptors globally, i.e, for all services and endpoints in a Bus;
however, suppose I want to install my interceptors at a finer level
of granularity, e.g., per endpoint. Is there a way for my plugin,
which seems to be loaded at Bus initialization time, to get a handle
on the Service or Endpoint (which also implement InterceptorProvider)
for which it is (or counterfactually would be) configured? Is this
an envisioned pattern? Or is there some other sort of interceptor I
don't know of, e.g, which hooks into Service or Endpoint creation?
Thanks!
-Fred
Hi Fred,
On the client side you can manage interceptors at the client, endpoint,
service and bus level. If you have created your proxy using JAXWS APIs,
you need to first obtain a reference to the underlying CXF client object
as follows:
BasicGreeterService gs = new BasicGreeterService();
Greeter greeter = gs.getGreeterPort();
org.apache.cxf.endpoint.Client client =
org.apache.cxf.frontend.ClientProxy.getClient(greeter);
client.getOutInterceptors().add(...);
org.apache.cxf.endpoint.Endpoint endpoint = client.getEndpoint();
endpoint.getOutInterceptors().add(...);
org.apache.cxf.service.Service service = endpoint.getService();
service.getOutInterceptors().add(...);
On the server side, if you use the JAXWS API, cast the
javax.xml.ws.Endpoint object you obtained from publish to get access to
its underlying CXF endpoint. Note that Server - unlike Client - is not
an interceptor provider, which is a bit asymmetric.
javax.xml.ws.Endpoint jaxwsEndpoint =
javax.xml.ws.Endpoint.publish("http://localhost:9020/SoapContext/GreeterPort";,
new GreeterImpl(););
LoggingOutInterceptor out = new LoggingOutInterceptor();
org.apache.cxf.jaxws.EndpointImpl jaxwsEndpointImpl =
(org.apache.cxf.jaxws.EndpointImpl)endpoint;
org.apache.cxf.endpoint.Server server = jaxwsEndpointImpl.getServer();
org.apache.cxf.endpoint.Endpoint endpoint = server.getEndpoint();
endpoint.getOutInterceptors().add(...);
org.apache.cxf.service.Service service = endpoint.getService();
service.getOutInterceptors().add(...);
You can also have an interceptor installed at bus level which, when
executing, adds further interceptors to the chain, possibly on a per
message basis. This is done for example in
org.apache.cxf.ws.policy.ClientPolicyOutInterceptor.
Cheers,
Andrea.
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Thank you, Jervis and Andrea. I think probably the last part of Andrea's response comes closest to the sort of thing I need: You can also have an interceptor installed at bus level which, when executing, adds further interceptors to the chain, possibly on a per message basis. This is done for example in org.apache.cxf.ws.policy.ClientPolicyOutInterceptor. (Jervis, I see what the code you referenced is doing, but does an ordinary developer like myself have a hook into the creation of an Endpoint? The code you reference seems to be a special case of installing a BindingFactory into an Endpoint, which is part of the CXF plumbing. I'm looking for something more in userland, as they say. Unless I'm missing something -- please correct me if I am.) The issue is that I want to programatically install these interceptors from plugin (i.e., spring-loaded) code, but it looks like there's really no way to do that. Andrea's solution (if I understand it -- apologies if I'm being thick) is to install an interceptor during the servicing of a request, which works, though I'd hoped I could avoid that sort of overhead -- it's something I really only need to do once, at the point at which the operative InterceptorProvider is being set-up or established. Also, if interceptors are being added in the course of servicing a request, does one have to take special care of thread-safety issues? I understand the InterceptorProvider returns you a List by reference, not a copy, so you are free to add, delete, traverse elements, etc. But if you're in the context of a request, is there any mechanism to lock access to the interceptor list, so that someone else in your application with the same devious plan won't walk over the same data at the same time? Am I completely missing something about the architecture, here? It seems like modifying an interceptor list in flight has ConcurrentModification exceptions written all over it. Thanks, -Fred
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
I just added some ways to specify interceptors for your endpoint or proxy: http://localhost:8080/test";> Or on the client side (which I don't have fancy spring 2.0 support for yet) http://endpoint/url"/> Also, I recently added an AbstractWSFeature class which I'd like to support the loading of a plugin for a particular scenario. The idea being that you can have a feature class - like a WSSecurityFeature - which configures your endpoint for something - like WS-Security. And it can just become part of the JAX-WS endpoint configuration. I posted some examples of how this might work in the client/EPR thread if you're interested. I'll be answering some of the questions that arose on that shortly... - Dan On 3/21/07, Fred Dushin <[EMAIL PROTECTED]> wrote: Thank you, Jervis and Andrea. I think probably the last part of Andrea's response comes closest to the sort of thing I need: > You can also have an interceptor installed at bus level which, when > executing, adds further interceptors to the chain, possibly on a > per message basis. This is done for example in > org.apache.cxf.ws.policy.ClientPolicyOutInterceptor. (Jervis, I see what the code you referenced is doing, but does an ordinary developer like myself have a hook into the creation of an Endpoint? The code you reference seems to be a special case of installing a BindingFactory into an Endpoint, which is part of the CXF plumbing. I'm looking for something more in userland, as they say. Unless I'm missing something -- please correct me if I am.) The issue is that I want to programatically install these interceptors from plugin (i.e., spring-loaded) code, but it looks like there's really no way to do that. Andrea's solution (if I understand it -- apologies if I'm being thick) is to install an interceptor during the servicing of a request, which works, though I'd hoped I could avoid that sort of overhead -- it's something I really only need to do once, at the point at which the operative InterceptorProvider is being set-up or established. Also, if interceptors are being added in the course of servicing a request, does one have to take special care of thread-safety issues? I understand the InterceptorProvider returns you a List by reference, not a copy, so you are free to add, delete, traverse elements, etc. But if you're in the context of a request, is there any mechanism to lock access to the interceptor list, so that someone else in your application with the same devious plan won't walk over the same data at the same time? Am I completely missing something about the architecture, here? It seems like modifying an interceptor list in flight has ConcurrentModification exceptions written all over it. Thanks, -Fred -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Answering my own question here, after consultation with some CXF devs.
The anwser is, the lists returned from interceptors are returned from
the InterceptorProviders can and should be thread-safe, but it's a
current limitation that they are not. I've submitted https://
issues.apache.org/jira/browse/CXF-480 and am running the build on a
patch, which I'll submit shortly.
This still does not mean that one is completely out of the woods --
concurrent access to the interceptor list is safe, but you are still
not guaranteed that another thread hasn't already added (or removed)
an interceptor you may be looking for as you traverse it.
In my particular case, this should not be an issue, since I have
control over which interceptor (types) I am looking for and
inserting, but buyer beware, in the general case.
I suppose a general pattern we might adopt and urge on applications
is to acquire a lock on the list, itself, whilst traversing and
inserting or removing elements, e.g.,
synchronized(interceptorList) {
// look for the interceptor I want to add
// if it's not there, add it
// leave a breadcrumb so I know I already inserted it
}
That sort of thing. Not sure what else can be said, other than a C++-
style ::insert.
Someone else mentioned that it might be nice to have he notion of an
interceptor id, which I'd fully agree with, so that you could do a
lookup by id. Your interceptor lists are then just (sortable) maps
(or multimaps, as the case may be), and lookup can be done in O(lg
n). But that's a pretty disruptive change to the whole
architecture. OTOH, better to do it now than once the cat is out of
the bag...
-Fred
On Mar 21, 2007, at 5:48 AM, Fred Dushin wrote:
Also, if interceptors are being added in the course of servicing a
request, does one have to take special care of thread-safety
issues? I understand the InterceptorProvider returns you a List by
reference, not a copy, so you are free to add, delete, traverse
elements, etc. But if you're in the context of a request, is there
any mechanism to lock access to the interceptor list, so that
someone else in your application with the same devious plan won't
walk over the same data at the same time? Am I completely missing
something about the architecture, here? It seems like modifying an
interceptor list in flight has ConcurrentModification exceptions
written all over it.
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Okay, that's interesting, if I understand what you intend. Is the idea that you install a feature on an endpoint (where the feature is manifest as a bean), and under the covers, the feature assembles all the pieces, in the correct order, etc? That's basically what I'm after, but I need access to the endpoint, so that I can install interceptors on that specific level of granularity. (Again, sort of fumbling around in the dark here, as I am not omniscient vis a vis CXF internals.) I'm not sure how the XML config you posted in the email I'm responding to is relevant, since I'm not trying to statically configure an interceptor -- I want all that to be done under the hood, by my FooFeature bean. Thanks! -Fred On Mar 21, 2007, at 3:12 PM, Dan Diephouse wrote: Also, I recently added an AbstractWSFeature class which I'd like to support the loading of a plugin for a particular scenario. The idea being that you can have a feature class - like a WSSecurityFeature - which configures your endpoint for something - like WS-Security. And it can just become part of the JAX-WS endpoint configuration. I posted some examples of how this might work in the client/EPR thread if you're interested. I'll be answering some of the questions that arose on that shortly...
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
> -Original Message- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 21 March 2007 19:12 > To: cxf-dev@incubator.apache.org > Cc: cxf-user@incubator.apache.org > Subject: Re: Programatically installing interceptors per > (Bus|Service|Endpoint) > > Also, I recently added an AbstractWSFeature class which I'd > like to support the loading of a plugin for a particular > scenario. The idea being that you can have a feature class - > like a WSSecurityFeature - which configures your endpoint for > something - like WS-Security. And it can just become part of > the JAX-WS endpoint configuration. I posted some examples of > how this might work in the client/EPR thread if you're > interested. I'll be answering some of the questions that > arose on that shortly... This WSFeature stuff is interesting. One quick question, what would be the overlap between this and the WS-Policy framework? I'm thinking specifically of the following policy use-case: - policy assertion implies requirement on runtime - corresponding AssertionBuilder indicates it has capability to support this requirement - corresponding PolicyInterceptorProvider contributes the necessary interceptors to realize the capability in the dispatch chain - dispatch-time policy verification ensures that this capability is present as expected Cheers, Eoghan
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
On 3/22/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: > -Original Message- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 21 March 2007 19:12 > To: cxf-dev@incubator.apache.org > Cc: cxf-user@incubator.apache.org > Subject: Re: Programatically installing interceptors per > (Bus|Service|Endpoint) > > Also, I recently added an AbstractWSFeature class which I'd > like to support the loading of a plugin for a particular > scenario. The idea being that you can have a feature class - > like a WSSecurityFeature - which configures your endpoint for > something - like WS-Security. And it can just become part of > the JAX-WS endpoint configuration. I posted some examples of > how this might work in the client/EPR thread if you're > interested. I'll be answering some of the questions that > arose on that shortly... This WSFeature stuff is interesting. One quick question, what would be the overlap between this and the WS-Policy framework? I'm thinking specifically of the following policy use-case: - policy assertion implies requirement on runtime - corresponding AssertionBuilder indicates it has capability to support this requirement - corresponding PolicyInterceptorProvider contributes the necessary interceptors to realize the capability in the dispatch chain - dispatch-time policy verification ensures that this capability is present as expected Thats an interesting idea as well. I guess I don't fully grok all the policy stuff. But I'll check into and see if we can just use that instead. No need to replicate that. Do you think there would there be an issue if we don't have a policy schema for particular features? - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
> -Original Message- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 22 March 2007 21:04 > To: cxf-dev@incubator.apache.org > Cc: cxf-user@incubator.apache.org > Subject: Re: Programatically installing interceptors per > (Bus|Service|Endpoint) > > On 3/22/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: > > > > > > > > > -Original Message- > > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > > > Sent: 21 March 2007 19:12 > > > To: cxf-dev@incubator.apache.org > > > Cc: cxf-user@incubator.apache.org > > > Subject: Re: Programatically installing interceptors per > > > (Bus|Service|Endpoint) > > > > > > Also, I recently added an AbstractWSFeature class which > I'd like to > > > support the loading of a plugin for a particular > scenario. The idea > > > being that you can have a feature class - like a > WSSecurityFeature - > > > which configures your endpoint for something - like > WS-Security. And > > > it can just become part of the JAX-WS endpoint configuration. I > > > posted some examples of how this might work in the > client/EPR thread > > > if you're interested. I'll be answering some of the > questions that > > > arose on that shortly... > > > > > > This WSFeature stuff is interesting. > > > > One quick question, what would be the overlap between this and the > > WS-Policy framework? > > > > I'm thinking specifically of the following policy use-case: > > - policy assertion implies requirement on runtime > > - corresponding AssertionBuilder indicates it has capability to > > support this requirement > > - corresponding PolicyInterceptorProvider contributes the necessary > > interceptors to realize the capability in the dispatch chain > > - dispatch-time policy verification ensures that this capability is > > present as expected > > > > Thats an interesting idea as well. I guess I don't fully grok > all the policy stuff. But I'll check into and see if we can > just use that instead. No need to replicate that. > > Do you think there would there be an issue if we don't have a > policy schema for particular features? Do you mean there not being a *standardized* policy schema for a particular feature? I guess in that case we could invent our own, or? Nothing against the WS*Feature idea in principle ... but probably worth thinking about a bit in terms of ensuring we don't end up with two different means (WS*Feature and WS-Policy) to a similar end (asserting a requirement on the runtime). Cheers, Eoghan
Re: Dynamically change interceptors in an interceptor chain?
Glen, On Monday 18 February 2008, Glen Mazza wrote: > Can I program an interceptor in a web service's incoming interceptor > chain to dynamically route to another interceptor other than the one > predefined in its chain (and ignore all subsequent interceptors in the > predefined chain)? Kind of yes. Basically, there are a couple ways to do it. One option is to grab the current InterceptorChain and remove everything you don't want (or comes after your interceptor).I believe you can just get the Iterator from the chain and use the remove methods on that. I think they are implemented.Then add in everything you do want. Another option is to create a whole new chain (you could have chains cached with the PhaseChainCache stuff) with the new stuff you want. In your interceptor, you would pause the current chain (so nothing else would get called later) and then call newChain.processmessage(msg); Dan > > In other words, for an interceptor chain A->B->C->D, can I add > business logic in interceptor A for it to route to A->E->F->G instead? > In particular, I would like to avoid it doing A->E->F->G->B->C->D if > I can, i.e., once I reroute, I don't want it to return to the other > interceptors in the predefined chain. > > Thanks, > Glen -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Dynamically change interceptors in an interceptor chain?
Glen, No. A "fresh" interceptor chain is used for each invocation. Thus, during the processing of the message, you can muck with is all you want and would have no impact on future invocations. Dan On Monday 18 February 2008, Glen Mazza wrote: > Dan, > > We're looking at the second option you gave below right now, but I > have a question on the first. If I grabbed the InterceptorChain below > as you say and modified it, would *all* subsequent web service > requests use that modified interceptor chain (which I don't want), or > would the business logic in interceptor A be activated each time, > letting it decide whether to continue on ->B->C->D (the default) or > ->E->F->G (the alternative as decided by A) (which I do want)? > > Thanks, > Glen > > PS - please forward your response to CXF-User, I'm operating outside > of Nabble right now. > > On Feb 18, 2008 10:23 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > Glen, > > > > On Monday 18 February 2008, Glen Mazza wrote: > > > Can I program an interceptor in a web service's incoming > > > interceptor chain to dynamically route to another interceptor > > > other than the one predefined in its chain (and ignore all > > > subsequent interceptors in the predefined chain)? > > > > Kind of yes. > > > > Basically, there are a couple ways to do it. One option is to grab > > the current InterceptorChain and remove everything you don't want > > (or comes after your interceptor).I believe you can just get the > > Iterator from the chain and use the remove methods on that. I think > > they are implemented.Then add in everything you do want. > > > > Another option is to create a whole new chain (you could have chains > > cached with the PhaseChainCache stuff) with the new stuff you want. > > In your interceptor, you would pause the current chain (so nothing > > else would get called later) and then call > > newChain.processmessage(msg); > > > > Dan > > > > > In other words, for an interceptor chain A->B->C->D, can I add > > > business logic in interceptor A for it to route to A->E->F->G > > > instead? In particular, I would like to avoid it doing > > > A->E->F->G->B->C->D if I can, i.e., once I reroute, I don't want > > > it to return to the other interceptors in the predefined chain. > > > > > > Thanks, > > > Glen > > > > -- > > J. Daniel Kulp > > Principal Engineer, IONA > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Adding interceptors to a JAX-WS client via the API
Hi I'm looking for some guidance on whether I can use the API to add interceptors to a JAX-WS client that was generated using the wsdl2java tool. I want to implement some ws-security functionality in the client and the documentation appears to indicate that adding a WSS4JOutInterceptor is the way to do this. Unfortunately, the documentation for the API usage for the client is a bit unclear (http://cwiki.apache.org/CXF20DOC/ws-security.html), it shows how to setup the properties for the interceptor clearly (although the usage of "outProps.setProperty" rather than "outProps.put" worries me slightly as outProps appears to be a Map) but not how to get the interceptor applied to the client. I've tried several attempts to do this but none have so far worked. I cannot find a way to get hold of an appropriate object instance that either implements the Client or InterceptorProvider interfaces. I have found an example that adds interceptors to the Bus but that applies them to all requests going through the bus whereas I only want to do it for a particular web service. Any guidance on this would be gratefully received, even it it's to say that I'm trying to do doing something that I shouldn't. Mark Mark Edwards Orchard Information Systems Limited, Newcastle Technopole, Kings Manor, Newcastle upon Tyne, NE1 6PA United Kingdom. Registered in England, Number 1900078 Tel: +44 (0)191-203 2500 Fax: +44 (0)191-230 2515 http://www.orchard-systems.co.uk <http://www.orchard-systems.co.uk/> This e-mail and any files transmitted are confidential and is solely for the intended recipient. Unauthorised use, dissemination, distribution, copying, reproduction, modification or publication is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail from your system. Opinions expressed in this e-mail are those of the individual and not necessarily those of Orchard Information Systems Ltd. It is the responsibility of the recipient to ensure this e-mail is free from viruses. Orchard Information Systems Ltd accept no liability for any damage caused by any virus transmitted by this e-mail. Incoming and outgoing e-mail messages are routinely monitored for compliance with Orchard Information Systems Ltd's Internet Usage Policy. Orchard Information Systems Ltd. Registered in England No. 1900078 Newcastle Technopole, Kings Manor, Newcastle upon Tyne, NE1 6PA Please consider the environment before printing this e-mail.
Re: Adding interceptors to a JAX-WS client via the API
Hi Mark, You can obtain a reference to the underlying CXF client object using the ClientProxy helper, for example: GreeterService gs = new GreeterService(); Greeter greeter = gs.getGreeterPort(); org.apache.cxf.endpoint.Client client = org.apache.cxf.frontend.ClientProxy.getClient(greeter); org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint(); cxfEndpoint.getOutInterceptors().add(...); Regards, Andrea. Mark Edwards wrote: Hi I'm looking for some guidance on whether I can use the API to add interceptors to a JAX-WS client that was generated using the wsdl2java tool. I want to implement some ws-security functionality in the client and the documentation appears to indicate that adding a WSS4JOutInterceptor is the way to do this. Unfortunately, the documentation for the API usage for the client is a bit unclear (http://cwiki.apache.org/CXF20DOC/ws-security.html), it shows how to setup the properties for the interceptor clearly (although the usage of "outProps.setProperty" rather than "outProps.put" worries me slightly as outProps appears to be a Map) but not how to get the interceptor applied to the client. I've tried several attempts to do this but none have so far worked. I cannot find a way to get hold of an appropriate object instance that either implements the Client or InterceptorProvider interfaces. I have found an example that adds interceptors to the Bus but that applies them to all requests going through the bus whereas I only want to do it for a particular web service. Any guidance on this would be gratefully received, even it it's to say that I'm trying to do doing something that I shouldn't. Mark Mark Edwards Orchard Information Systems Limited, Newcastle Technopole, Kings Manor, Newcastle upon Tyne, NE1 6PA United Kingdom. Registered in England, Number 1900078 Tel: +44 (0)191-203 2500 Fax: +44 (0)191-230 2515 http://www.orchard-systems.co.uk <http://www.orchard-systems.co.uk/> This e-mail and any files transmitted are confidential and is solely for the intended recipient. Unauthorised use, dissemination, distribution, copying, reproduction, modification or publication is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail from your system. Opinions expressed in this e-mail are those of the individual and not necessarily those of Orchard Information Systems Ltd. It is the responsibility of the recipient to ensure this e-mail is free from viruses. Orchard Information Systems Ltd accept no liability for any damage caused by any virus transmitted by this e-mail. Incoming and outgoing e-mail messages are routinely monitored for compliance with Orchard Information Systems Ltd's Internet Usage Policy. Orchard Information Systems Ltd. Registered in England No. 1900078 Newcastle Technopole, Kings Manor, Newcastle upon Tyne, NE1 6PA Please consider the environment before printing this e-mail. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Adding interceptors to a JAX-WS client via the API
Hi Andrea Thanks for this, works a treat. Regards Mark -Original Message- From: Andrea Smyth [mailto:[EMAIL PROTECTED] Sent: 08 August 2007 10:29 To: cxf-user@incubator.apache.org Subject: Re: Adding interceptors to a JAX-WS client via the API Hi Mark, You can obtain a reference to the underlying CXF client object using the ClientProxy helper, for example: GreeterService gs = new GreeterService(); Greeter greeter = gs.getGreeterPort(); org.apache.cxf.endpoint.Client client = org.apache.cxf.frontend.ClientProxy.getClient(greeter); org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint(); cxfEndpoint.getOutInterceptors().add(...); Regards, Andrea. Mark Edwards wrote: >Hi > > > >I'm looking for some guidance on whether I can use the API to add >interceptors to a JAX-WS client that was generated using the wsdl2java tool. >I want to implement some ws-security functionality in the client and the >documentation appears to indicate that adding a WSS4JOutInterceptor is the >way to do this. Unfortunately, the documentation for the API usage for the >client is a bit unclear (http://cwiki.apache.org/CXF20DOC/ws-security.html), >it shows how to setup the properties for the interceptor clearly (although >the usage of "outProps.setProperty" rather than "outProps.put" worries me >slightly as outProps appears to be a Map) but not how to get the interceptor >applied to the client. > > > >I've tried several attempts to do this but none have so far worked. I cannot >find a way to get hold of an appropriate object instance that either >implements the Client or InterceptorProvider interfaces. I have found an >example that adds interceptors to the Bus but that applies them to all >requests going through the bus whereas I only want to do it for a particular >web service. > > > >Any guidance on this would be gratefully received, even it it's to say that >I'm trying to do doing something that I shouldn't. > > > > > >Mark > > > > > >Mark Edwards > >Orchard Information Systems Limited, >Newcastle Technopole, Kings Manor, >Newcastle upon Tyne, >NE1 6PA >United Kingdom. >Registered in England, Number 1900078 >Tel: +44 (0)191-203 2500 Fax: +44 (0)191-230 2515 >http://www.orchard-systems.co.uk <http://www.orchard-systems.co.uk/> > > > > >This e-mail and any files transmitted are confidential and is solely for the intended recipient. Unauthorised use, dissemination, distribution, copying, reproduction, modification or publication is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail from your system. >Opinions expressed in this e-mail are those of the individual and not necessarily those of Orchard Information Systems Ltd. > >It is the responsibility of the recipient to ensure this e-mail is free from viruses. Orchard Information Systems Ltd accept no liability for any damage caused by any virus transmitted by this e-mail. > >Incoming and outgoing e-mail messages are routinely monitored for compliance with Orchard Information Systems Ltd's Internet Usage Policy. > >Orchard Information Systems Ltd. Registered in England No. 1900078 >Newcastle Technopole, Kings Manor, Newcastle upon Tyne, NE1 6PA > >Please consider the environment before printing this e-mail. > > > > > IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland This e-mail and any files transmitted are confidential and is solely for the intended recipient. Unauthorised use, dissemination, distribution, copying, reproduction, modification or publication is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail from your system. Opinions expressed in this e-mail are those of the individual and not necessarily those of Orchard Information Systems Ltd. It is the responsibility of the recipient to ensure this e-mail is free from viruses. Orchard Information Systems Ltd accept no liability for any damage caused by any virus transmitted by this e-mail. Incoming and outgoing e-mail messages are routinely monitored for compliance with Orchard Information Systems Ltd's Internet Usage Policy. Orchard Information Systems Ltd. Registered in England No. 1900078 Newcastle Technopole, Kings Manor, Newcastle upon Tyne, NE1 6PA Please consider the environment before printing this e-mail.
RE: Adding interceptors to a JAX-WS client via the API
This blog entry by Arsenalist may also be of help for you: http://arsenalist.com/2007/07/31/cxf-ws-security-using-jsr-181-interceptor-annotations-xfire-migration/ Glen Am Mittwoch, den 08.08.2007, 10:55 +0100 schrieb Mark Edwards: > Hi Andrea > > Thanks for this, works a treat. > > Regards > > Mark > > -Original Message- > From: Andrea Smyth [mailto:[EMAIL PROTECTED] > Sent: 08 August 2007 10:29 > To: cxf-user@incubator.apache.org > Subject: Re: Adding interceptors to a JAX-WS client via the API > > Hi Mark, > > You can obtain a reference to the underlying CXF client object using the > ClientProxy helper, for example: > > GreeterService gs = new GreeterService(); > Greeter greeter = gs.getGreeterPort(); > > org.apache.cxf.endpoint.Client client = > org.apache.cxf.frontend.ClientProxy.getClient(greeter); > org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint(); > cxfEndpoint.getOutInterceptors().add(...); > > Regards, > Andrea. > > > > Mark Edwards wrote: > > >Hi > > > > > > > >I'm looking for some guidance on whether I can use the API to add > >interceptors to a JAX-WS client that was generated using the wsdl2java tool. > >I want to implement some ws-security functionality in the client and the > >documentation appears to indicate that adding a WSS4JOutInterceptor is the > >way to do this. Unfortunately, the documentation for the API usage for the > >client is a bit unclear (http://cwiki.apache.org/CXF20DOC/ws-security.html), > >it shows how to setup the properties for the interceptor clearly (although > >the usage of "outProps.setProperty" rather than "outProps.put" worries me > >slightly as outProps appears to be a Map) but not how to get the interceptor > >applied to the client. > > > > > > > >I've tried several attempts to do this but none have so far worked. I > cannot > >find a way to get hold of an appropriate object instance that either > >implements the Client or InterceptorProvider interfaces. I have found an > >example that adds interceptors to the Bus but that applies them to all > >requests going through the bus whereas I only want to do it for a particular > >web service. > > > > > > > >Any guidance on this would be gratefully received, even it it's to say that > >I'm trying to do doing something that I shouldn't. > > > > > > > > > > > >Mark > > > > > > > > > > > >Mark Edwards > > > >Orchard Information Systems Limited, > >Newcastle Technopole, Kings Manor, > >Newcastle upon Tyne, > >NE1 6PA > >United Kingdom. > >Registered in England, Number 1900078 > >Tel: +44 (0)191-203 2500 Fax: +44 (0)191-230 2515 > >http://www.orchard-systems.co.uk <http://www.orchard-systems.co.uk/> > > > > > > > > > >This e-mail and any files transmitted are confidential and is solely for the > intended recipient. Unauthorised use, dissemination, distribution, copying, > reproduction, modification or publication is strictly prohibited. If you have > received this e-mail in error, please notify the sender and permanently > delete the e-mail from your system. > >Opinions expressed in this e-mail are those of the individual and not > necessarily those of Orchard Information Systems Ltd. > > > >It is the responsibility of the recipient to ensure this e-mail is free from > viruses. Orchard Information Systems Ltd accept no liability for any damage > caused by any virus transmitted by this e-mail. > > > >Incoming and outgoing e-mail messages are routinely monitored for compliance > with Orchard Information Systems Ltd's Internet Usage Policy. > > > >Orchard Information Systems Ltd. Registered in England No. 1900078 > >Newcastle Technopole, Kings Manor, Newcastle upon Tyne, NE1 6PA > > > >Please consider the environment before printing this e-mail. > > > > > > > > > > > > > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland > > This e-mail and any files transmitted are confidential and is solely for the > intended recipient. Unauthorised use, dissemination, distribution, copying, > reproduction, modification or publication is strictly prohibited. If you have > received this e-mail in error, please notify the sender and permanently > delete the e-mail from your system. > Opinions expressed in this
Re: Adding interceptors to a JAX-WS client via the API
On Wednesday 08 August 2007 20:23, Glen Mazza wrote: > This blog entry by Arsenalist may also be of help for you: > http://arsenalist.com/2007/07/31/cxf-ws-security-using-jsr-181-interce >ptor-annotations-xfire-migration/ That blog describes how to use the interceptors via annotations on the Server side. (BTW: thats a very nicely done example. Thanks for that link.) Unfortunately, even with 2.0.1, that doesn't work on the client side. It DOES work on trunk now. Dan > Glen > > Am Mittwoch, den 08.08.2007, 10:55 +0100 schrieb Mark Edwards: > > Hi Andrea > > > > Thanks for this, works a treat. > > > > Regards > > > > Mark > > > > -Original Message- > > From: Andrea Smyth [mailto:[EMAIL PROTECTED] > > Sent: 08 August 2007 10:29 > > To: cxf-user@incubator.apache.org > > Subject: Re: Adding interceptors to a JAX-WS client via the API > > > > Hi Mark, > > > > You can obtain a reference to the underlying CXF client object using > > the ClientProxy helper, for example: > > > > GreeterService gs = new GreeterService(); > > Greeter greeter = gs.getGreeterPort(); > > > > org.apache.cxf.endpoint.Client client = > > org.apache.cxf.frontend.ClientProxy.getClient(greeter); > > org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint(); > > cxfEndpoint.getOutInterceptors().add(...); > > > > Regards, > > Andrea. > > > > Mark Edwards wrote: > > >Hi > > > > > > > > > > > >I'm looking for some guidance on whether I can use the API to add > > >interceptors to a JAX-WS client that was generated using the > > > wsdl2java tool. I want to implement some ws-security functionality > > > in the client and the documentation appears to indicate that > > > adding a WSS4JOutInterceptor is the way to do this. > > > Unfortunately, the documentation for the API usage for the client > > > is a bit unclear > > > (http://cwiki.apache.org/CXF20DOC/ws-security.html), it shows how > > > to setup the properties for the interceptor clearly (although the > > > usage of "outProps.setProperty" rather than "outProps.put" worries > > > me slightly as outProps appears to be a Map) but not how to get > > > the interceptor applied to the client. > > > > > > > > > > > >I've tried several attempts to do this but none have so far worked. > > > I > > > > cannot > > > > >find a way to get hold of an appropriate object instance that > > > either implements the Client or InterceptorProvider interfaces. I > > > have found an example that adds interceptors to the Bus but that > > > applies them to all requests going through the bus whereas I only > > > want to do it for a particular web service. > > > > > > > > > > > >Any guidance on this would be gratefully received, even it it's to > > > say that I'm trying to do doing something that I shouldn't. > > > > > > > > > > > > > > > > > >Mark > > > > > > > > > > > > > > > > > >Mark Edwards > > > > > >Orchard Information Systems Limited, > > >Newcastle Technopole, Kings Manor, > > >Newcastle upon Tyne, > > >NE1 6PA > > >United Kingdom. > > >Registered in England, Number 1900078 > > >Tel: +44 (0)191-203 2500 Fax: +44 (0)191-230 2515 > > >http://www.orchard-systems.co.uk > > > <http://www.orchard-systems.co.uk/> > > > > > > > > > > > > > > >This e-mail and any files transmitted are confidential and is > > > solely for the > > > > intended recipient. Unauthorised use, dissemination, distribution, > > copying, reproduction, modification or publication is strictly > > prohibited. If you have received this e-mail in error, please notify > > the sender and permanently delete the e-mail from your system. > > > > >Opinions expressed in this e-mail are those of the individual and > > > not > > > > necessarily those of Orchard Information Systems Ltd. > > > > >It is the responsibility of the recipient to ensure this e-mail is > > > free from > > > > viruses. Orchard Information Systems Ltd accept no liability for any > > damage caused by any virus transmitted by this e-mail. > > > > >Incoming and outgoing e-mail messages are routinely monitored for > > > compliance > &
Re: Adding interceptors to a JAX-WS client via the API
Hi Andrea,
I noticed that you gave the following example to get a reference to the
underlying CXF client object:
You can obtain a reference to the underlying CXF client object using the
ClientProxy helper, for example:
GreeterService gs = new GreeterService();
Greeter greeter = gs.getGreeterPort();
org.apache.cxf.endpoint.Client client =
org.apache.cxf.frontend.ClientProxy.getClient(greeter);
org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint();
cxfEndpoint.getOutInterceptors().add(...);
Regards,
Andrea.
This works fine locally but when I attempt to deploy to BEA Weblogic 10.0 I
am having issues.
java.lang.reflect.InvocationHandler h =
java.lang.reflect.Proxy.getInvocationHandler(membershipInquiryPort);
System.out.println("InvocationHandler Object: " + h);
org.apache.cxf.jaxws.JaxWsClientProxy jaxClient =
(org.apache.cxf.jaxws.JaxWsClientProxy)h;
Locally this prints out:
[EMAIL PROTECTED]
On the WebLogic Server:
InvocationHandler Object: unknown: Stub for http://blah/
Anyone have any ideas why this is?
-Jeff
smime.p7s
Description: S/MIME cryptographic signature
Re: Adding interceptors to a JAX-WS client via the API
Hi Jeff,
Is it possible that theWeblogic server uses a different implementation
of javax.xml.ws.spi.Provider, i.e. is there another
META-INF/services/javax.xml.ws.Provider file on the classpath, before
the one in the cxf-rt-frontend-jaxws jar?
This would not affect the creation of a JAX-WS endpoint as in that case
the implementation class is defined by the BeanDefinitionParser for the
jaxws:endpoint elements in your cxf-servlet.xml file, but it would
impact the creation of a proxy if it's done as outlined below.
Andrea.
Tchang, Jeffrey (Genworth) wrote:
Hi Andrea,
I noticed that you gave the following example to get a reference to the
underlying CXF client object:
You can obtain a reference to the underlying CXF client object using the
ClientProxy helper, for example:
GreeterService gs = new GreeterService();
Greeter greeter = gs.getGreeterPort();
org.apache.cxf.endpoint.Client client =
org.apache.cxf.frontend.ClientProxy.getClient(greeter);
org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint();
cxfEndpoint.getOutInterceptors().add(...);
Regards,
Andrea.
This works fine locally but when I attempt to deploy to BEA Weblogic 10.0 I
am having issues.
java.lang.reflect.InvocationHandler h =
java.lang.reflect.Proxy.getInvocationHandler(membershipInquiryPort);
System.out.println("InvocationHandler Object: " + h);
org.apache.cxf.jaxws.JaxWsClientProxy jaxClient =
(org.apache.cxf.jaxws.JaxWsClientProxy)h;
Locally this prints out:
[EMAIL PROTECTED]
On the WebLogic Server:
InvocationHandler Object: unknown: Stub for http://blah/
Anyone have any ideas why this is?
-Jeff
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Problem having multiple interceptors of the same type on the interceptor chain?
We have a homebrew CXF interceptor which extends AbstractSoapInterceptor. It's a generic XSLT interceptor which runs the input through a specified XSLT. We use two of them in our interceptor chain, configuring them with different XSLTs. However, CXF ignores the second interceptor. It seems like since AbstractPhaseInterceptor uses the class name for its ID, the second interceptor is assumed to be a duplicate of the first. The simplest workaround is to create an additional interceptor class for each XSLT with different names, "XsltInterceptorKludge2.java" and "XsltInterceptorKludge3.java". A more complex workaround is to have our interceptor class have a static counter which increments with each created instance. Is this intended behavior of AbstractPhaseInterceptor? It seems unusual to assume that implementors will only want to have one instance of a given interceptor in the interceptor chain. -- View this message in context: http://www.nabble.com/Problem-having-multiple-interceptors-of-the-same-type-on-the-interceptor-chain--tp15300074p15300074.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem having multiple interceptors of the same type on the interceptor chain?
PhaseInterceptorChain[1] has "add" methods (lines 155 and 169) with a "force" parameter, that, if true, will apparently force the interceptor to be added to the chain (lines 475-496), even if there is another interceptor with the same name. I guess if you subclass PIC and just override the add() methods at line 151 and 165 to set a force value of "true" instead of "false", that would work. However, this force method is apparently highly infrequently used so I don't know how well tested out it is. Another issue is how to get CXF to use this subclass of PhaseInterceptorChain instead of PIC itself. Anyone know this? Unless I'm missing something, it really looks like this needs to be made more user-friendly. Regards, Glen [1] http://tinyurl.com/ytxfzk Am Dienstag, den 05.02.2008, 15:25 -0800 schrieb Aaron Pieper: > We have a homebrew CXF interceptor which extends AbstractSoapInterceptor. > It's a generic XSLT interceptor which runs the input through a specified > XSLT. We use two of them in our interceptor chain, configuring them with > different XSLTs. However, CXF ignores the second interceptor. It seems like > since AbstractPhaseInterceptor uses the class name for its ID, the second > interceptor is assumed to be a duplicate of the first. > > The simplest workaround is to create an additional interceptor class for > each XSLT with different names, "XsltInterceptorKludge2.java" and > "XsltInterceptorKludge3.java". > > A more complex workaround is to have our interceptor class have a static > counter which increments with each created instance. > > Is this intended behavior of AbstractPhaseInterceptor? It seems unusual to > assume that implementors will only want to have one instance of a given > interceptor in the interceptor chain.
Re: Problem having multiple interceptors of the same type on the interceptor chain?
This is actually as designed as a bunch of the interceptors will behave strangely if put twice in the same chain. As an example, lets say you have the logging feature configured on the bus, but also have it configured for the endpoint and also a @Feature thing on the code itself. The logging interceptors would then be added three times which would cause some very strange behavior as well as some HUGE performance problems. Another example would be the WS-Addressing interceptors as they each would be processing the addressing headers and sending back partial responses and stuff.If that was configured in multiple places, all kinds of issues would pop up. What might be a workable solution would be to add a method like: boolean allowDuplicates(); to PhaseInterceptor (default it to false in AbstractPhaseInterceptor for compatibility) where an interceptor could say "I'm allowed to be in here more than once". Feel free to log a JIRA for this. (and attach a patch :-) ) BTW: if you can send in a unique ID into the contructor, you can be OK now. AbstractPhaseInterceptor has a constructor where the ID can be passed in. Dan On Tuesday 05 February 2008, Aaron Pieper wrote: > We have a homebrew CXF interceptor which extends > AbstractSoapInterceptor. It's a generic XSLT interceptor which runs > the input through a specified XSLT. We use two of them in our > interceptor chain, configuring them with different XSLTs. However, CXF > ignores the second interceptor. It seems like since > AbstractPhaseInterceptor uses the class name for its ID, the second > interceptor is assumed to be a duplicate of the first. > > The simplest workaround is to create an additional interceptor class > for each XSLT with different names, "XsltInterceptorKludge2.java" and > "XsltInterceptorKludge3.java". > > A more complex workaround is to have our interceptor class have a > static counter which increments with each created instance. > > Is this intended behavior of AbstractPhaseInterceptor? It seems > unusual to assume that implementors will only want to have one > instance of a given interceptor in the interceptor chain. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Problem having multiple interceptors of the same type on the interceptor chain?
https://issues.apache.org/jira/browse/CXF-1418 Thanks for the insight. As an end-user configuring CXF's behavior through XML, it's kind of weird to have CXF's behavior not match the XML I'm giving it, so I don't agree with keeping the current behavior as the default. However, I understand that it makes things simpler for the built-in components, so I guess it's a compromise. dkulp wrote: > > What might be a workable solution would be to add a method like: > > boolean allowDuplicates(); > > to PhaseInterceptor (default it to false in AbstractPhaseInterceptor for > compatibility) where an interceptor could say "I'm allowed to be in here > more than once". > > Feel free to log a JIRA for this. (and attach a patch :-) ) > > On Tuesday 05 February 2008, Aaron Pieper wrote: >> We have a homebrew CXF interceptor which extends >> AbstractSoapInterceptor. It's a generic XSLT interceptor which runs >> the input through a specified XSLT. We use two of them in our >> interceptor chain, configuring them with different XSLTs. However, CXF >> ignores the second interceptor. It seems like since >> AbstractPhaseInterceptor uses the class name for its ID, the second >> interceptor is assumed to be a duplicate of the first. > -- View this message in context: http://www.nabble.com/Problem-having-multiple-interceptors-of-the-same-type-on-the-interceptor-chain--tp15300074p15306508.html Sent from the cxf-user mailing list archive at Nabble.com.
