You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Quilleash, Michael (IT)" <Mi...@MorganStanley.com> on 2008/09/21 12:22:58 UTC
"Around" interceptor
Hi all,
Could someone suggest how I might go about building an interceptor that has similar logic/behaviour as a try/finally clause. For example if I wanted to add timing logic I would need code to start/stop the timer.
Normally, in code I would do this
// TODO: begin timing
try
{
// invoke something
}
finally
{
// TODO: stop timing
}
But in CXF I can't find a way of doing this with a single interceptor. I would need to have:
In Interceptor - start timing
Out/InFault/OutFault interceptors - stop timing
To catch all the possible code paths. Is there any easier way of doing this?
Any help appreciated.
Cheers.
Michael Quilleash
Morgan Stanley | Technology
20 Cabot Square | Canary Wharf | Floor 01
London, E14 4QW
Phone: +44 20 7677-4543
Michael.Quilleash@MorganStanley.com<ma...@MorganStanley.com>
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
RE: "Around" interceptor
Posted by "Quilleash, Michael (IT)" <Mi...@MorganStanley.com>.
Thanks Ian, seems like the best approach.
Cheers.
Michael Quilleash
Morgan Stanley | Technology
20 Cabot Square | Canary Wharf | Floor 01
London, E14 4QW
Phone: +44 20 7677-4543
Michael.Quilleash@MorganStanley.com
-----Original Message-----
From: Ian Roberts [mailto:i.roberts@dcs.shef.ac.uk]
Sent: 21 September 2008 13:42
To: users@cxf.apache.org
Subject: Re: "Around" interceptor
Quilleash, Michael (IT) wrote:
> Thanks for the reply Ian.
>
> I did see this approach being used by the default interceptors,
> however I found out that the out/outFault messages are always null
> when the "in" interceptor is invoked so the interceptor chains aren't
> available to add new interceptors to.
>
> I haven't found an example of any interceptors that add interceptors
> to different interceptor chains.
>
> Is there a way of doing what you are saying, perhaps by creating the
> out messages earlier?
Hmm. In that case you might be better off just keeping the start and stop interceptors separate and creating a "feature" (see LoggingFeature for an example) to group them together. That way it's still a single configuration operation to add both interceptors - just add the feature to the bus, server, client, whatever.
Ian
--
Ian Roberts | Department of Computer Science
i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: "Around" interceptor
Posted by Ian Roberts <i....@dcs.shef.ac.uk>.
Quilleash, Michael (IT) wrote:
> Thanks for the reply Ian.
>
> I did see this approach being used by the default interceptors,
> however I found out that the out/outFault messages are always null
> when the "in" interceptor is invoked so the interceptor chains aren't
> available to add new interceptors to.
>
> I haven't found an example of any interceptors that add interceptors
> to different interceptor chains.
>
> Is there a way of doing what you are saying, perhaps by creating the
> out messages earlier?
Hmm. In that case you might be better off just keeping the start and
stop interceptors separate and creating a "feature" (see LoggingFeature
for an example) to group them together. That way it's still a single
configuration operation to add both interceptors - just add the feature
to the bus, server, client, whatever.
Ian
--
Ian Roberts | Department of Computer Science
i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
Re: "Around" interceptor
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 23 September 2008 11:10:57 am Quilleash, Michael (IT) wrote:
> Looking at the code it looks like the following would happen with an
> exception on the out chain...
>
> - OutgoingChainInterceptor invoked
> - Outgoing chain interceptor chain runs
> - Exception
> - Outgoing chain is unwound
> - OutgoingChainInterceptor completes
> - Any other "in" interceptors then run (usually none)
>
> So it looks like an in interceptor after the OutgoingChainInterceptor will
> always run, unless there's an exception on the inbound chain, in which case
> handleFault() would be called on my main in interceptor :)
The one case it doesn't "completely" cover is an exception on the inbound
chain. In that case, your handleFault will be called, but then the OutFault
chain will be constructed and your interceptor wouldn't have any actions on
that chain. Not sure if that's a big deal.
> One thing I noticed, should the PhaseInterceptorChain.unwind() method be
> more defensive when calling handleFault(), by catching/logging/swallowing
> any exceptions thrown from handleFault()?
Probably not a bad idea. :-) Feel free to log a jira (with a patch). :-)
Dan
>
> Cheers.
>
> Michael Quilleash
> Morgan Stanley | Technology
> 20 Cabot Square | Canary Wharf | Floor 01
> London, E14 4QW
> Phone: +44 20 7677-4543
> Michael.Quilleash@MorganStanley.com
>
> -----Original Message-----
> From: Quilleash, Michael (IT)
> Sent: 23 September 2008 15:27
> To: Daniel Kulp; users@cxf.apache.org
> Subject: RE: "Around" interceptor
>
> Ah that sounds good. Be ideal if I only had to register one interceptor
> and have it drive everything.
>
> So would I be right that if I did the following:
>
> - Add an in interceptor to the start of the in chain
> - Implement the handleFault() to do the "finally" code
> - In handleMessage() add a new interceptor right at the end of the in
> chain, which also does the "finally" code.
>
> Does this cover every case? What happens if an exception occurs in the
> outbound chain, does this propogate back and always unwind the in chain
> too?
>
> Cheers.
>
> Michael Quilleash
> Morgan Stanley | Technology
> 20 Cabot Square | Canary Wharf | Floor 01 London, E14 4QW
> Phone: +44 20 7677-4543
> Michael.Quilleash@MorganStanley.com
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: 23 September 2008 14:15
> To: users@cxf.apache.org
> Cc: Quilleash, Michael (IT)
> Subject: Re: "Around" interceptor
>
> On Tuesday 23 September 2008 9:04:23 am Quilleash, Michael (IT) wrote:
> > Thanks Dan,
> >
> > I see what you mean.
> >
> > But I guess that wouldn't work as a "finally" check tho as an
> > exeception in the chain causes the rest of the interceptors not to be
> > run. I would still have to add something to the fault chains to do the
> > finally stuff.
>
> Yep.
>
> Note: your interceptor at the start of the "in" chain can also implement
> the handleFault message which is called when the chain is unwinding but
> before the fault chain is called. You can then get timing information or
> something for the "in" chain part separate from the fault stuff.
>
> Dan
>
> > Cheers.
> >
> > Michael Quilleash
> > Morgan Stanley | Technology
> > 20 Cabot Square | Canary Wharf | Floor 01 London, E14 4QW
> > Phone: +44 20 7677-4543
> > Michael.Quilleash@MorganStanley.comy the contents of an OutputStream for
the out interceptor. I
looked at your logging interceptor and found that you used a
CacheAndWriteOutputStream. I tried using this in my out interceptor. I
registered a CachedOutputStreamCallback that handles the transformation in
the onClose method. The problem I have is that when I call
message.setContent() and pass it an output stream with my modified message,
it is not used. I'm assuming that I'm using the CacheAndWriteOutputStream
incorrectly. Do you have any suggestions on how I should be transforming the
contents of the OutputStream?
> >
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: 22 September 2008 19:39
> > To: users@cxf.apache.org
> > Cc: Quilleash, Michael (IT)
> > Subject: Re: "Around" interceptor
> >
> > On Sunday 21 September 2008 8:13:54 am Quilleash, Michael (IT) wrote:
> > > Thanks for the reply Ian.
> > >
> > > I did see this approach being used by the default interceptors,
> > > however I found out that the out/outFault messages are always null
> > > when the "in" interceptor is invoked so the interceptor chains
> > > aren't available to add new interceptors to.
> > >
> > > I haven't found an example of any interceptors that add interceptors
> > > to different interceptor chains.
> >
> > Yea, that's very hard to do. The chains aren't created until they are
> > actually needed. In a "one way" case, there would never even be an
> > "out" chain created or called.
> >
> > On the server side, the "simple" way to do it is to add your "stop"
> > interceptor to the VERY VERY end of the chain. If there is an out
> > message, the last interceptor on the "in" chain is the one that sets up
> > the out message/chain and calls it. Thus, your interceptor would be
> > invoked after that.
> >
> > Dan
> >
> > > Is there a way of doing what you are saying, perhaps by creating the
> > > out messages earlier?
> > >
> > > Cheers.
> > >
> > > -----Original Message-----
> > > From: Ian Roberts [mailto:i.roberts@dcs.shef.ac.uk]
> > > Sent: 21 September 2008 12:50
> > > To: users@cxf.apache.org
> > > Subject: Re: "Around" interceptor
> > >
> > > Quilleash, Michael (IT) wrote:
> > > > I would need to have:
> > > >
> > > > In Interceptor - start timing
> > > > Out/InFault/OutFault interceptors - stop timing
> > > >
> > > > To catch all the possible code paths. Is there any easier way of
> > > > doing this?
> > >
> > > A trick used in a number of CXF built-in interceptors is to have a
> > > main interceptor which is added to the chain explicitly, but then
> > > have that interceptor add others to the relevant chains for that
> > > exchange during its handleMessage. For example (pseudo-code):
> > >
> > > class TimingInterceptor {
> > > private Interceptor stopTiming = new StopTimingInterceptor();
> > >
> > > handleMessage(Message m) {
> > > Exchange ex = m.getExchange();
> > > ex.put("startTime", System.currentTimeMillis());
> > > ex.getOutMessage().getInterceptorChain().add(stopTiming);
> > > ex.getOutFaultMessage().getInterceptorChain().add(stopTiming);
> > > }
> > >
> > > static class StopTimingInterceptor {
> > > handleMessage(Message m) {
> > > Exchange ex = m.getExchange();
> > > long startTime = ex.get("startTime");
> > > // ...
> > > }
> > > }
> > > }
> > >
> > > You only need to add the TimingInterceptor to your input chain and
> > > it will manage the rest for you.
> > >
> > > Ian
> > >
> > > --
> > > Ian Roberts | Department of Computer Science
> > > i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
> > > --------------------------------------------------------
> > >
> > > NOTICE: If received in error, please destroy and notify sender.
> > > Sender does not intend to waive confidentiality or privilege. Use of
> > > this email is prohibited when received in error.
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender. Sender
> > does not intend to waive confidentiality or privilege. Use of this
> > email is prohibited when received in error.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
RE: "Around" interceptor
Posted by "Quilleash, Michael (IT)" <Mi...@MorganStanley.com>.
Looking at the code it looks like the following would happen with an exception on the out chain...
- OutgoingChainInterceptor invoked
- Outgoing chain interceptor chain runs
- Exception
- Outgoing chain is unwound
- OutgoingChainInterceptor completes
- Any other "in" interceptors then run (usually none)
So it looks like an in interceptor after the OutgoingChainInterceptor will always run, unless there's an exception on the inbound chain, in which case handleFault() would be called on my main in interceptor :)
One thing I noticed, should the PhaseInterceptorChain.unwind() method be more defensive when calling handleFault(), by catching/logging/swallowing any exceptions thrown from handleFault()?
Cheers.
Michael Quilleash
Morgan Stanley | Technology
20 Cabot Square | Canary Wharf | Floor 01
London, E14 4QW
Phone: +44 20 7677-4543
Michael.Quilleash@MorganStanley.com
-----Original Message-----
From: Quilleash, Michael (IT)
Sent: 23 September 2008 15:27
To: Daniel Kulp; users@cxf.apache.org
Subject: RE: "Around" interceptor
Ah that sounds good. Be ideal if I only had to register one interceptor and have it drive everything.
So would I be right that if I did the following:
- Add an in interceptor to the start of the in chain
- Implement the handleFault() to do the "finally" code
- In handleMessage() add a new interceptor right at the end of the in chain, which also does the "finally" code.
Does this cover every case? What happens if an exception occurs in the outbound chain, does this propogate back and always unwind the in chain too?
Cheers.
Michael Quilleash
Morgan Stanley | Technology
20 Cabot Square | Canary Wharf | Floor 01 London, E14 4QW
Phone: +44 20 7677-4543
Michael.Quilleash@MorganStanley.com
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: 23 September 2008 14:15
To: users@cxf.apache.org
Cc: Quilleash, Michael (IT)
Subject: Re: "Around" interceptor
On Tuesday 23 September 2008 9:04:23 am Quilleash, Michael (IT) wrote:
> Thanks Dan,
>
> I see what you mean.
>
> But I guess that wouldn't work as a "finally" check tho as an
> exeception in the chain causes the rest of the interceptors not to be
> run. I would still have to add something to the fault chains to do the finally stuff.
Yep.
Note: your interceptor at the start of the "in" chain can also implement the handleFault message which is called when the chain is unwinding but before
the fault chain is called. You can then get timing information or something
for the "in" chain part separate from the fault stuff.
Dan
>
> Cheers.
>
> Michael Quilleash
> Morgan Stanley | Technology
> 20 Cabot Square | Canary Wharf | Floor 01 London, E14 4QW
> Phone: +44 20 7677-4543
> Michael.Quilleash@MorganStanley.com
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: 22 September 2008 19:39
> To: users@cxf.apache.org
> Cc: Quilleash, Michael (IT)
> Subject: Re: "Around" interceptor
>
> On Sunday 21 September 2008 8:13:54 am Quilleash, Michael (IT) wrote:
> > Thanks for the reply Ian.
> >
> > I did see this approach being used by the default interceptors,
> > however I found out that the out/outFault messages are always null
> > when the "in" interceptor is invoked so the interceptor chains
> > aren't available to add new interceptors to.
> >
> > I haven't found an example of any interceptors that add interceptors
> > to different interceptor chains.
>
> Yea, that's very hard to do. The chains aren't created until they are
> actually needed. In a "one way" case, there would never even be an "out"
> chain created or called.
>
> On the server side, the "simple" way to do it is to add your "stop"
> interceptor to the VERY VERY end of the chain. If there is an out
> message, the last interceptor on the "in" chain is the one that sets up the
> out message/chain and calls it. Thus, your interceptor would be invoked
> after that.
>
> Dan
>
> > Is there a way of doing what you are saying, perhaps by creating the
> > out messages earlier?
> >
> > Cheers.
> >
> > -----Original Message-----
> > From: Ian Roberts [mailto:i.roberts@dcs.shef.ac.uk]
> > Sent: 21 September 2008 12:50
> > To: users@cxf.apache.org
> > Subject: Re: "Around" interceptor
> >
> > Quilleash, Michael (IT) wrote:
> > > I would need to have:
> > >
> > > In Interceptor - start timing
> > > Out/InFault/OutFault interceptors - stop timing
> > >
> > > To catch all the possible code paths. Is there any easier way of
> > > doing this?
> >
> > A trick used in a number of CXF built-in interceptors is to have a
> > main interceptor which is added to the chain explicitly, but then
> > have that interceptor add others to the relevant chains for that
> > exchange during its handleMessage. For example (pseudo-code):
> >
> > class TimingInterceptor {
> > private Interceptor stopTiming = new StopTimingInterceptor();
> >
> > handleMessage(Message m) {
> > Exchange ex = m.getExchange();
> > ex.put("startTime", System.currentTimeMillis());
> > ex.getOutMessage().getInterceptorChain().add(stopTiming);
> > ex.getOutFaultMessage().getInterceptorChain().add(stopTiming);
> > }
> >
> > static class StopTimingInterceptor {
> > handleMessage(Message m) {
> > Exchange ex = m.getExchange();
> > long startTime = ex.get("startTime");
> > // ...
> > }
> > }
> > }
> >
> > You only need to add the TimingInterceptor to your input chain and
> > it will manage the rest for you.
> >
> > Ian
> >
> > --
> > Ian Roberts | Department of Computer Science
> > i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender.
> > Sender does not intend to waive confidentiality or privilege. Use of
> > this email is prohibited when received in error.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
RE: "Around" interceptor
Posted by "Quilleash, Michael (IT)" <Mi...@MorganStanley.com>.
Ah that sounds good. Be ideal if I only had to register one interceptor and have it drive everything.
So would I be right that if I did the following:
- Add an in interceptor to the start of the in chain
- Implement the handleFault() to do the "finally" code
- In handleMessage() add a new interceptor right at the end of the in chain, which also does the "finally" code.
Does this cover every case? What happens if an exception occurs in the outbound chain, does this propogate back and always unwind the in chain too?
Cheers.
Michael Quilleash
Morgan Stanley | Technology
20 Cabot Square | Canary Wharf | Floor 01
London, E14 4QW
Phone: +44 20 7677-4543
Michael.Quilleash@MorganStanley.com
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: 23 September 2008 14:15
To: users@cxf.apache.org
Cc: Quilleash, Michael (IT)
Subject: Re: "Around" interceptor
On Tuesday 23 September 2008 9:04:23 am Quilleash, Michael (IT) wrote:
> Thanks Dan,
>
> I see what you mean.
>
> But I guess that wouldn't work as a "finally" check tho as an
> exeception in the chain causes the rest of the interceptors not to be
> run. I would still have to add something to the fault chains to do the finally stuff.
Yep.
Note: your interceptor at the start of the "in" chain can also implement the handleFault message which is called when the chain is unwinding but before
the fault chain is called. You can then get timing information or something
for the "in" chain part separate from the fault stuff.
Dan
>
> Cheers.
>
> Michael Quilleash
> Morgan Stanley | Technology
> 20 Cabot Square | Canary Wharf | Floor 01 London, E14 4QW
> Phone: +44 20 7677-4543
> Michael.Quilleash@MorganStanley.com
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: 22 September 2008 19:39
> To: users@cxf.apache.org
> Cc: Quilleash, Michael (IT)
> Subject: Re: "Around" interceptor
>
> On Sunday 21 September 2008 8:13:54 am Quilleash, Michael (IT) wrote:
> > Thanks for the reply Ian.
> >
> > I did see this approach being used by the default interceptors,
> > however I found out that the out/outFault messages are always null
> > when the "in" interceptor is invoked so the interceptor chains
> > aren't available to add new interceptors to.
> >
> > I haven't found an example of any interceptors that add interceptors
> > to different interceptor chains.
>
> Yea, that's very hard to do. The chains aren't created until they are
> actually needed. In a "one way" case, there would never even be an "out"
> chain created or called.
>
> On the server side, the "simple" way to do it is to add your "stop"
> interceptor to the VERY VERY end of the chain. If there is an out
> message, the last interceptor on the "in" chain is the one that sets up the
> out message/chain and calls it. Thus, your interceptor would be invoked
> after that.
>
> Dan
>
> > Is there a way of doing what you are saying, perhaps by creating the
> > out messages earlier?
> >
> > Cheers.
> >
> > -----Original Message-----
> > From: Ian Roberts [mailto:i.roberts@dcs.shef.ac.uk]
> > Sent: 21 September 2008 12:50
> > To: users@cxf.apache.org
> > Subject: Re: "Around" interceptor
> >
> > Quilleash, Michael (IT) wrote:
> > > I would need to have:
> > >
> > > In Interceptor - start timing
> > > Out/InFault/OutFault interceptors - stop timing
> > >
> > > To catch all the possible code paths. Is there any easier way of
> > > doing this?
> >
> > A trick used in a number of CXF built-in interceptors is to have a
> > main interceptor which is added to the chain explicitly, but then
> > have that interceptor add others to the relevant chains for that
> > exchange during its handleMessage. For example (pseudo-code):
> >
> > class TimingInterceptor {
> > private Interceptor stopTiming = new StopTimingInterceptor();
> >
> > handleMessage(Message m) {
> > Exchange ex = m.getExchange();
> > ex.put("startTime", System.currentTimeMillis());
> > ex.getOutMessage().getInterceptorChain().add(stopTiming);
> > ex.getOutFaultMessage().getInterceptorChain().add(stopTiming);
> > }
> >
> > static class StopTimingInterceptor {
> > handleMessage(Message m) {
> > Exchange ex = m.getExchange();
> > long startTime = ex.get("startTime");
> > // ...
> > }
> > }
> > }
> >
> > You only need to add the TimingInterceptor to your input chain and
> > it will manage the rest for you.
> >
> > Ian
> >
> > --
> > Ian Roberts | Department of Computer Science
> > i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender.
> > Sender does not intend to waive confidentiality or privilege. Use of
> > this email is prohibited when received in error.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: "Around" interceptor
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 23 September 2008 9:04:23 am Quilleash, Michael (IT) wrote:
> Thanks Dan,
>
> I see what you mean.
>
> But I guess that wouldn't work as a "finally" check tho as an exeception in
> the chain causes the rest of the interceptors not to be run. I would still
> have to add something to the fault chains to do the finally stuff.
Yep.
Note: your interceptor at the start of the "in" chain can also implement the
handleFault message which is called when the chain is unwinding but before
the fault chain is called. You can then get timing information or something
for the "in" chain part separate from the fault stuff.
Dan
>
> Cheers.
>
> Michael Quilleash
> Morgan Stanley | Technology
> 20 Cabot Square | Canary Wharf | Floor 01
> London, E14 4QW
> Phone: +44 20 7677-4543
> Michael.Quilleash@MorganStanley.com
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: 22 September 2008 19:39
> To: users@cxf.apache.org
> Cc: Quilleash, Michael (IT)
> Subject: Re: "Around" interceptor
>
> On Sunday 21 September 2008 8:13:54 am Quilleash, Michael (IT) wrote:
> > Thanks for the reply Ian.
> >
> > I did see this approach being used by the default interceptors,
> > however I found out that the out/outFault messages are always null when
> > the "in" interceptor is invoked so the interceptor chains aren't
> > available to add new interceptors to.
> >
> > I haven't found an example of any interceptors that add interceptors
> > to different interceptor chains.
>
> Yea, that's very hard to do. The chains aren't created until they are
> actually needed. In a "one way" case, there would never even be an "out"
> chain created or called.
>
> On the server side, the "simple" way to do it is to add your "stop"
> interceptor to the VERY VERY end of the chain. If there is an out
> message, the last interceptor on the "in" chain is the one that sets up the
> out message/chain and calls it. Thus, your interceptor would be invoked
> after that.
>
> Dan
>
> > Is there a way of doing what you are saying, perhaps by creating the
> > out messages earlier?
> >
> > Cheers.
> >
> > -----Original Message-----
> > From: Ian Roberts [mailto:i.roberts@dcs.shef.ac.uk]
> > Sent: 21 September 2008 12:50
> > To: users@cxf.apache.org
> > Subject: Re: "Around" interceptor
> >
> > Quilleash, Michael (IT) wrote:
> > > I would need to have:
> > >
> > > In Interceptor - start timing
> > > Out/InFault/OutFault interceptors - stop timing
> > >
> > > To catch all the possible code paths. Is there any easier way of
> > > doing this?
> >
> > A trick used in a number of CXF built-in interceptors is to have a
> > main interceptor which is added to the chain explicitly, but then have
> > that interceptor add others to the relevant chains for that exchange
> > during its handleMessage. For example (pseudo-code):
> >
> > class TimingInterceptor {
> > private Interceptor stopTiming = new StopTimingInterceptor();
> >
> > handleMessage(Message m) {
> > Exchange ex = m.getExchange();
> > ex.put("startTime", System.currentTimeMillis());
> > ex.getOutMessage().getInterceptorChain().add(stopTiming);
> > ex.getOutFaultMessage().getInterceptorChain().add(stopTiming);
> > }
> >
> > static class StopTimingInterceptor {
> > handleMessage(Message m) {
> > Exchange ex = m.getExchange();
> > long startTime = ex.get("startTime");
> > // ...
> > }
> > }
> > }
> >
> > You only need to add the TimingInterceptor to your input chain and it
> > will manage the rest for you.
> >
> > Ian
> >
> > --
> > Ian Roberts | Department of Computer Science
> > i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender. Sender
> > does not intend to waive confidentiality or privilege. Use of this
> > email is prohibited when received in error.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
RE: "Around" interceptor
Posted by "Quilleash, Michael (IT)" <Mi...@MorganStanley.com>.
Thanks Dan,
I see what you mean.
But I guess that wouldn't work as a "finally" check tho as an exeception in the chain causes the rest of the interceptors not to be run. I would still have to add something to the fault chains to do the finally stuff.
Cheers.
Michael Quilleash
Morgan Stanley | Technology
20 Cabot Square | Canary Wharf | Floor 01
London, E14 4QW
Phone: +44 20 7677-4543
Michael.Quilleash@MorganStanley.com
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: 22 September 2008 19:39
To: users@cxf.apache.org
Cc: Quilleash, Michael (IT)
Subject: Re: "Around" interceptor
On Sunday 21 September 2008 8:13:54 am Quilleash, Michael (IT) wrote:
> Thanks for the reply Ian.
>
> I did see this approach being used by the default interceptors,
> however I found out that the out/outFault messages are always null when the "in"
> interceptor is invoked so the interceptor chains aren't available to
> add new interceptors to.
>
> I haven't found an example of any interceptors that add interceptors
> to different interceptor chains.
Yea, that's very hard to do. The chains aren't created until they are
actually needed. In a "one way" case, there would never even be an "out"
chain created or called.
On the server side, the "simple" way to do it is to add your "stop"
interceptor to the VERY VERY end of the chain. If there is an out message,
the last interceptor on the "in" chain is the one that sets up the out
message/chain and calls it. Thus, your interceptor would be invoked after
that.
Dan
> Is there a way of doing what you are saying, perhaps by creating the
> out messages earlier?
>
> Cheers.
>
> -----Original Message-----
> From: Ian Roberts [mailto:i.roberts@dcs.shef.ac.uk]
> Sent: 21 September 2008 12:50
> To: users@cxf.apache.org
> Subject: Re: "Around" interceptor
>
> Quilleash, Michael (IT) wrote:
> > I would need to have:
> >
> > In Interceptor - start timing
> > Out/InFault/OutFault interceptors - stop timing
> >
> > To catch all the possible code paths. Is there any easier way of
> > doing this?
>
> A trick used in a number of CXF built-in interceptors is to have a
> main interceptor which is added to the chain explicitly, but then have
> that interceptor add others to the relevant chains for that exchange
> during its handleMessage. For example (pseudo-code):
>
> class TimingInterceptor {
> private Interceptor stopTiming = new StopTimingInterceptor();
>
> handleMessage(Message m) {
> Exchange ex = m.getExchange();
> ex.put("startTime", System.currentTimeMillis());
> ex.getOutMessage().getInterceptorChain().add(stopTiming);
> ex.getOutFaultMessage().getInterceptorChain().add(stopTiming);
> }
>
> static class StopTimingInterceptor {
> handleMessage(Message m) {
> Exchange ex = m.getExchange();
> long startTime = ex.get("startTime");
> // ...
> }
> }
> }
>
> You only need to add the TimingInterceptor to your input chain and it
> will manage the rest for you.
>
> Ian
>
> --
> Ian Roberts | Department of Computer Science
> i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: "Around" interceptor
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday 21 September 2008 8:13:54 am Quilleash, Michael (IT) wrote:
> Thanks for the reply Ian.
>
> I did see this approach being used by the default interceptors, however I
> found out that the out/outFault messages are always null when the "in"
> interceptor is invoked so the interceptor chains aren't available to add
> new interceptors to.
>
> I haven't found an example of any interceptors that add interceptors to
> different interceptor chains.
Yea, that's very hard to do. The chains aren't created until they are
actually needed. In a "one way" case, there would never even be an "out"
chain created or called.
On the server side, the "simple" way to do it is to add your "stop"
interceptor to the VERY VERY end of the chain. If there is an out message,
the last interceptor on the "in" chain is the one that sets up the out
message/chain and calls it. Thus, your interceptor would be invoked after
that.
Dan
> Is there a way of doing what you are saying, perhaps by creating the out
> messages earlier?
>
> Cheers.
>
> -----Original Message-----
> From: Ian Roberts [mailto:i.roberts@dcs.shef.ac.uk]
> Sent: 21 September 2008 12:50
> To: users@cxf.apache.org
> Subject: Re: "Around" interceptor
>
> Quilleash, Michael (IT) wrote:
> > I would need to have:
> >
> > In Interceptor - start timing
> > Out/InFault/OutFault interceptors - stop timing
> >
> > To catch all the possible code paths. Is there any easier way of
> > doing this?
>
> A trick used in a number of CXF built-in interceptors is to have a main
> interceptor which is added to the chain explicitly, but then have that
> interceptor add others to the relevant chains for that exchange during its
> handleMessage. For example (pseudo-code):
>
> class TimingInterceptor {
> private Interceptor stopTiming = new StopTimingInterceptor();
>
> handleMessage(Message m) {
> Exchange ex = m.getExchange();
> ex.put("startTime", System.currentTimeMillis());
> ex.getOutMessage().getInterceptorChain().add(stopTiming);
> ex.getOutFaultMessage().getInterceptorChain().add(stopTiming);
> }
>
> static class StopTimingInterceptor {
> handleMessage(Message m) {
> Exchange ex = m.getExchange();
> long startTime = ex.get("startTime");
> // ...
> }
> }
> }
>
> You only need to add the TimingInterceptor to your input chain and it will
> manage the rest for you.
>
> Ian
>
> --
> Ian Roberts | Department of Computer Science
> i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
RE: "Around" interceptor
Posted by "Quilleash, Michael (IT)" <Mi...@MorganStanley.com>.
Thanks for the reply Ian.
I did see this approach being used by the default interceptors, however I found out that the out/outFault messages are always null when the "in" interceptor is invoked so the interceptor chains aren't available to add new interceptors to.
I haven't found an example of any interceptors that add interceptors to different interceptor chains.
Is there a way of doing what you are saying, perhaps by creating the out messages earlier?
Cheers.
-----Original Message-----
From: Ian Roberts [mailto:i.roberts@dcs.shef.ac.uk]
Sent: 21 September 2008 12:50
To: users@cxf.apache.org
Subject: Re: "Around" interceptor
Quilleash, Michael (IT) wrote:
> I would need to have:
>
> In Interceptor - start timing
> Out/InFault/OutFault interceptors - stop timing
>
> To catch all the possible code paths. Is there any easier way of
> doing this?
A trick used in a number of CXF built-in interceptors is to have a main interceptor which is added to the chain explicitly, but then have that interceptor add others to the relevant chains for that exchange during its handleMessage. For example (pseudo-code):
class TimingInterceptor {
private Interceptor stopTiming = new StopTimingInterceptor();
handleMessage(Message m) {
Exchange ex = m.getExchange();
ex.put("startTime", System.currentTimeMillis());
ex.getOutMessage().getInterceptorChain().add(stopTiming);
ex.getOutFaultMessage().getInterceptorChain().add(stopTiming);
}
static class StopTimingInterceptor {
handleMessage(Message m) {
Exchange ex = m.getExchange();
long startTime = ex.get("startTime");
// ...
}
}
}
You only need to add the TimingInterceptor to your input chain and it will manage the rest for you.
Ian
--
Ian Roberts | Department of Computer Science
i.roberts@dcs.shef.ac.uk | University of Sheffield, UK
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: "Around" interceptor
Posted by Ian Roberts <i....@dcs.shef.ac.uk>.
Quilleash, Michael (IT) wrote:
> I would need to have:
>
> In Interceptor - start timing
> Out/InFault/OutFault interceptors - stop timing
>
> To catch all the possible code paths. Is there any easier way of
> doing this?
A trick used in a number of CXF built-in interceptors is to have a main
interceptor which is added to the chain explicitly, but then have that
interceptor add others to the relevant chains for that exchange during
its handleMessage. For example (pseudo-code):
class TimingInterceptor {
private Interceptor stopTiming = new StopTimingInterceptor();
handleMessage(Message m) {
Exchange ex = m.getExchange();
ex.put("startTime", System.currentTimeMillis());
ex.getOutMessage().getInterceptorChain().add(stopTiming);
ex.getOutFaultMessage().getInterceptorChain().add(stopTiming);
}
static class StopTimingInterceptor {
handleMessage(Message m) {
Exchange ex = m.getExchange();
long startTime = ex.get("startTime");
// ...
}
}
}
You only need to add the TimingInterceptor to your input chain and it
will manage the rest for you.
Ian
--
Ian Roberts | Department of Computer Science
i.roberts@dcs.shef.ac.uk | University of Sheffield, UK