Why does LoggingOutInterceptor use callback, but LoggingInInterceptor does not?

["KARR, DAVID (ATTSI)" <dk...@att.com>]

I've concluded that writing a custom logging interceptor requires
writing it from scratch, as opposed to trying to use the
Logging{Out,In}Interceptor as a base class or assuming it was executed
previously in the chain.  I've tried both of those approaches, and they
reach dead ends.

So, I'm starting with the Logging{Out,In}Interceptor and trying to write
a single abstract class such that the subclass can be created as either
a IN or OUT interceptor.

I'm examining the two classes, LoggingOutInterceptor and
LoggingInInterceptor.  I notice that they are similar, but different.
They are different specifically in the "handleMessage()" method.  The
"Out" one uses CacheAndWriteOutputStream and registers a callback object
to handle the result.  The "In" one just reads from the InputStream into
a CachedOutputStream.  After that point, they both work similarly, as
they both have a CachedOutputStream and read from that into a
StringBuilder.

The "Out" interceptor is set in the PRE_STREAM phase, and the "In" is in
the RECEIVE phase.  In that context, I guess I can understand why the
"Out" interceptor sets up a callback, but the "In" interceptor just
reads the content.  Why exactly is the "Out" interceptor using
PRE_STREAM, as opposed to a later phase after the data has been
streamed?  Is this done because the data is unavailable at that point?

Re: Why does LoggingOutInterceptor use callback, but LoggingInInterceptor does not?

[Daniel Kulp <dk...@apache.org>]

On Friday 05 November 2010 12:57:56 pm KARR, DAVID (ATTSI) wrote:
> I've concluded that writing a custom logging interceptor requires
> writing it from scratch, as opposed to trying to use the
> Logging{Out,In}Interceptor as a base class or assuming it was executed
> previously in the chain.  I've tried both of those approaches, and they
> reach dead ends.

One option:
Figure out what changes could be done to Logging{Out,In}Interceptor to make it 
more ammendable to subclassing or configuring and submit those changes to CXF 
for inclusion in 2.3.1.   We love to see patches.     :-)


Dan



> 
> So, I'm starting with the Logging{Out,In}Interceptor and trying to write
> a single abstract class such that the subclass can be created as either
> a IN or OUT interceptor.
> 
> I'm examining the two classes, LoggingOutInterceptor and
> LoggingInInterceptor.  I notice that they are similar, but different.
> They are different specifically in the "handleMessage()" method.  The
> "Out" one uses CacheAndWriteOutputStream and registers a callback object
> to handle the result.  The "In" one just reads from the InputStream into
> a CachedOutputStream.  After that point, they both work similarly, as
> they both have a CachedOutputStream and read from that into a
> StringBuilder.
> 
> The "Out" interceptor is set in the PRE_STREAM phase, and the "In" is in
> the RECEIVE phase.  In that context, I guess I can understand why the
> "Out" interceptor sets up a callback, but the "In" interceptor just
> reads the content.  Why exactly is the "Out" interceptor using
> PRE_STREAM, as opposed to a later phase after the data has been
> streamed?  Is this done because the data is unavailable at that point?

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Why does LoggingOutInterceptor use callback, but LoggingInInterceptor does not?

[Jason Pell <ja...@pellcorp.com>]

Hi,

My understanding of this is that you have to get in early in the Out
interceptor chain before
any other interceptor has started writing to the OuputStream.  You
swap the original output
stream with a cached one and none of the other interceptors are the
wiser.  You then come
back in the callback (which is new in 2.3.0 I think - as it was
different in 2.2.10) and get all the
cached output and log it and then swap back in the original
outputstream so it can be closed
as part of the message sender interceptor.

This new class CacheAndWriteOutputStream means that the original
stream keeps getting
written to, whereas my understanding originally the CachedOutputStream
completely usurped
the original stream until the later Logger interceptor swapped them back.

As for the incoming stream for logging, if you are early enough in the
chain, you can get hold of
the inputstream and make a copy of it.  Log the output and put the
copy back in as the InputStream
content.  None of the other interceptors will be any the wiser up the
line as they just need the
input stream, which will be replaced with an XML Stream Reader or
something fairly soon anyway.

Not sure if I have helped, I am not a developer but I have spent a
couple of months neck deep
in all of this :-)

Cheers
Jason

On Sat, Nov 6, 2010 at 3:57 AM, KARR, DAVID (ATTSI) <dk...@att.com> wrote:
> I've concluded that writing a custom logging interceptor requires
> writing it from scratch, as opposed to trying to use the
> Logging{Out,In}Interceptor as a base class or assuming it was executed
> previously in the chain.  I've tried both of those approaches, and they
> reach dead ends.
>
> So, I'm starting with the Logging{Out,In}Interceptor and trying to write
> a single abstract class such that the subclass can be created as either
> a IN or OUT interceptor.
>
> I'm examining the two classes, LoggingOutInterceptor and
> LoggingInInterceptor.  I notice that they are similar, but different.
> They are different specifically in the "handleMessage()" method.  The
> "Out" one uses CacheAndWriteOutputStream and registers a callback object
> to handle the result.  The "In" one just reads from the InputStream into
> a CachedOutputStream.  After that point, they both work similarly, as
> they both have a CachedOutputStream and read from that into a
> StringBuilder.
>
> The "Out" interceptor is set in the PRE_STREAM phase, and the "In" is in
> the RECEIVE phase.  In that context, I guess I can understand why the
> "Out" interceptor sets up a callback, but the "In" interceptor just
> reads the content.  Why exactly is the "Out" interceptor using
> PRE_STREAM, as opposed to a later phase after the data has been
> streamed?  Is this done because the data is unavailable at that point?
>