cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "KARR, DAVID (ATTSI)" <dk0...@att.com>
Subject RE: Best way to get XML string in interceptor
Date Thu, 04 Nov 2010 17:27:47 GMT
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Wednesday, November 03, 2010 7:55 PM
> To: users@cxf.apache.org
> Cc: KARR, DAVID (ATTSI)
> Subject: Re: Best way to get XML string in interceptor
> 
> On Wednesday 03 November 2010 7:28:24 pm KARR, DAVID (ATTSI) wrote:
> > > -----Original Message-----
> > > From: KARR, DAVID (ATTSI)
> > > Sent: Wednesday, November 03, 2010 2:33 PM
> > > To: users@cxf.apache.org
> > > Subject: Best way to get XML string in interceptor
> > >
> > > I need to write some in/out interceptors that do something with
the
> > > incoming or outgoing XML string, but not modifying it for
> downstream
> > > interceptors or the eventual handler.  They are basically logging
> > > interceptors, like the LoggingOutInterceptor.
> > >
> > > How can I write a custom interceptor that can read the XML string,
> but
> > > still let the handler process it normally?
> > >
> > > It seems like subclassing LoggingOutInterceptor might work, and
> >
> > perhaps
> >
> > > setting the "writer" just before calling the
> "super.handleMessage()"
> > > method.  I tried this, but the writer ended up with an empty
> string.
> >
> > I can see why I ended up with an empty string.
LoggingOutInterceptor
> > writes the output asynchronously, so the writer doesn't get the data
> > until sometimes after the function returns.  I wish I could plug my
> own
> > callback into LoggingOutInterceptor, so I could implement
> > application-specific handling.  As it is, I guess I'm going to have
> to
> > duplicate most of what LoggingOutInterceptor is doing.
> 
> Well, if you write an interceptor that lives immediately after the
> LoggingOutInterceptor, you should be able to grab the Outputstream,
> cast it to
> the CacheAndWriteOutputStream, add your callback.

In this context, what is the purpose of the "LOG_SETUP" key that
LoggingOutInterceptor is checking for?  It looks like it deals with
LoggingOutInterceptor being in the interceptor chain twice, although I
don't know why it would do that.

Should a custom interceptor that works similarly be doing something with
this key also?

Mime
View raw message