More selective Logging(In|Out)Interceptor

["Beilin, Vadim" <Va...@morganstanley.com>]

Hello,

Some of our applications need to be more selective about what information CXF logging interceptors print. Some parameters are sensitive information, etc.
We introduced a custom annotation to mark REST methods  that must be suppressed from logging.

(In what follows I use LoggingInInterceptor to demonstrate the issue, but it is applicable to LoggingOutInterceptor as well.)

When trying to reuse existing logging interceptors, we run into a problem - LoggingInInterceptor must run early enough in the chain to substitute input stream, but there is not enough information to decide on logging at this point. OperationResourceInfo is only resolved in UNMARSHAL.
For us it means that logging interceptor has to be split in two. The first part running in RECEIVE creates and substitutes InputStream, the second, in PRE_LOGICAL, decides if and how the incoming information would be logged.

First question - is there some existing way to achieve this without writing our own interceptors that we missed?

Second question - do you think it would make sense to change Logging*Interceptors to do this sort of things easier?
Two possibilities come to mind. One, which is what we are doing now, is to split out StreamCachingInteceptor, and have LoggingInInterceptor check whether the input stream has already been implemented (e.g. add a flag to the message). Then we can extend LoggingInInterceptor, putting the subclass to a later phase and checking if logging must be suppressed in handleMessage.
The interceptor chain looks like:
  ...
  RECEIVE - StreamCachingInterceptor ...
  ...
  PRE_LOGICAL - OurLoggingInInterceptor extends LoggingInterceptor
  ...

The other possibility is to introduce new protected method AbstractLoggingInterceptor.log(Message, Logger, String) that would call the existing method log(Logger, String). Then one has a chance to override it to store the log entry in the message instead, and do actual logging later, in a different interceptor. The chain then looks like this:
  ...
  RECEIVE - PrepareLoggingInInterceptor extends LoggingInInterceptor
  ...
  PRE_LOGICAL - CheckAndLogPreparedEntryInterceptor
  ...

What do you think?

Vadim


________________________________

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.