dump message logging based on Mbean

[maeste]

Looking at some issues about redirection of message logging made by cxf or metro, I thought that these feature can be ignored in favor of a more general message dumping. With this approach we would have an unique configuration (independent from the stack) to enable message dumping, we would have message dumping also for native stack, and moreover we can made something more sophisticated than simple dumping (for example start and stopping dynamically, or saving somewhere messages for a time frame to analyze it).

My idea is to make an MBean doing the job (receiving servlet request response, logging messages, eventually making something more with them) invoked by RequestHandler. Of course RequestHandler have to become an abstract class (now it is an interface) and some refactoring is needed.
Moreover users have a single configuration to change to dump messages not depending from the stack used, and the behaviour can be changed runtime from jmx-console.

Any opinion about?

[heiko.braun]

I like the idea. Just a few thoughts on this topic:

- Working on in/output streams: We need to be careful with double buffering here. It might easily neglect the performance improvemts within each stack.

- Abstract RequestHandler. This is part of the SPI and cannot easily be changed. If you need to work on it, do it soon With the next release the SPI will not easily undergo changes.

[maeste]

I like the idea. Just a few thoughts on this topic:

- Working on in/output streams: We need to be careful with double buffering here. It might easily neglect the performance improvemts within each stack.

Right. Indeed we have to be careful, but I immagine this feature as normal disabled, and enabled only during debug when performance isn't so important

- Abstract RequestHandler. This is part of the SPI and cannot easily be changed. If you need to work on it, do it soon With the next release the SPI will not easily undergo changes.

When you have time, can you explain a little more what is going to happen to spi?
BTW, I thin I'll put my hand there next week, I would finish at least a snapshot version of WISE before ;)

[thomas.diesler]

Yes, thats a good idea.

I don't think the SPI is a limiting factor. Currently each stack installs its proprietary RequestHandler.

We could add a deployment aspect that depends on the ReqestHandler being set and that installs a MessageLoggingRequestHandler that delegates to the original one.