On Oct 10, 2007, at 5:46 AM, Emmanuel Lecharny wrote:
Hi, I was just wondering if we should not be able to initialize the logger dynamically ? Using an extended operation to start or stop the logger seems appropriate.
What is the use case for turning it on and off while the server is running? Usually when you introduce runtime configurability like this you need to either synchronize something on the runtime path or introduce a volatile to assure that the component is using completely initialized and configured objects, and this can easily add up in speed costs.
I also think that the Interceptor I'm working on is not really a log interceptor, as it stores anti-modification, and not the modifications themselves. Should we create another interceptor, or should we store the anti-modification somewhere else? As those anti-modification must be applied in revert order, a file is not really the most appropriate solution. For what we want to use it (reverting to a previous state) we can store the anti-modifications in a stack, in memory. Thoughts ?
Why not store a complete representation of the change as a modification and compute the anti-modification only if it is needed? Then the log can also work as a transaction journal. I have no idea how hard figuring out a complete representation of the change is -- your other post made it sound like it has a lot of complexity.
thanks david jencks
-- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
