On Thu, 3 Nov 2005, Mark Womack wrote: | The wrapper class would only be in 1.2 and really only used to avoid making | everyone take the "big" change in the new version of 1.2. I am assuming that | we will do the right thing in 1.3 to not require the use of the wrapper | class. | | The wrapper class would need to have a special (and potentially clumsy) | syntax for configuring the wrapper class. Something like: | | <parameter key="property" value="(key)(value)"/> | | where key and value would be the property name and value to set. The | setProperty method in the wrapper class would parse and set the | property/value in the wrapped class. Unless there is something we can do | more with bytecode manipulation.
Couldn't one "just" make a special-case for the wrapper? So that if the configuration parts of log4j saw the wrapper class specified, if would -not- set the properties on the wrapper, but on the wrappee? (except for maybe special ones, e.g. starting with "Wrapper:" for key..) This brings me to the next point: what about "just" introducing a new Appender API (a new interface, that is)? In this way, the log4j core (configuration system, basically) could "sense" whether it was an old Appender (simply instanceof), and thus automatically wrap it, and set the properties in the way mentioned above (on the wrappee), or if it was the new Appender2, it would configure and use it natively? The old threads on this list about the subject are also interesting. For my part, the coarse-level synching seems the most worrisome, and Elias suggestions here for a way more fine grained synching sounds very interesting. Contended synchs (which you'd have -often- given the way I've understood log4j actually works) are rather expensive, and something you'd get a lot in a very multi-threaded application as a webapplication is. Just my 2 øre. Regards, Endre.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
