| that's very intriguing on face value. Bit of maintenance effort? If this is for 1.2, are you saying that a 1.3 upgrade by our users would be required to 'drop' their use of the wrapper classes in favour of something else, or do you see these wrapper impl's staying supported features longer term?
I'm a bit confused by the "....wrapper class will not have getter/setters for the class being wrapped"... How does the configuration of the 'wrapped' class get configured?
Paul On 04/11/2005, at 1:09 PM, Mark Womack wrote: OK, stop me if this sounds completely crazy. It might.
What if we created a wrapper class for subclasses of AppenderSkeleton that implemented Elias's version of doAppend with the changed synchronization logic? That wrapper class would be part of the 1.2 release but would not be used in the current classes, meaning that the current code would be in place by default, not messing anyone up right away.
But, if desired, the user could use the new wrapper class to wrap the existing subclasses of AppenderSkeleton, and they could control it all from the configuration file. They would specify the wrapper class for the appender class, parameters would specify the class they want to wrap and the specific parameters to set. The wrapper class would just do call thrus to the class being wrapped, except for the doAppend call, which would be new behavior. Some care would need to taken to support the property settings since the wrapper class will not have getter/setters for the class being wrapped.
Does that sound too wacky? It would preserve the existing log4j 1.2 api, but would give users some recourse to correct the locking problem if they are seeing it. I need to look at more code, but thought I would bounce it out there.
-Mark
On 11/3/05, Mark Womack <[EMAIL PROTECTED]> wrote: Yes, it is on the "list" for 1.3.
The last message in the thread is from 10/21. Do you have any update since then? I really hate leaving this hanging in 1.2. I would like to find a solution that does not break subclasses of AppenderSkeleton. Don't know what that would be yet.
-Mark
On 10/31/05, Elias Ross < [EMAIL PROTECTED]> wrote:
For your information: Log4j has the potential to create deadlocks at
the message rendering step. The JBoss team has been working on fixing
this issue.
http://jira.jboss.com/jira/browse/JBAS-2393
Scott Stark is trying two approaches. One is to fix the synchronization
code used in log4j 1.2.12 in JBoss through a patch, which may break user
appenders. The other is to create log4j-style appenders and DOM
configuration support for the JDK logging framework. You can read more
in the forum thread linked from the issue.
(This issue I opened about 2 years ago and hasn't really seen much
attention. http://issues.apache.org/bugzilla/show_bug.cgi?id=24159 )
I don't expect this to be fixed for 1.2, but I would hope it gets
addressed for 1.3 as part of the "must-fix list" for 1.3.
I'm not sure what sort of reasonable fix might be employed for the main
framework, I'm hoping to discuss that here.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
smime.p7s
Description: S/MIME cryptographic signature
