bugzilla | 2 Nov 16:06 2005
Picon

DO NOT REPLY [Bug 32752] - MDC.put and MDC.get signatures changed between 1.2 and 1.3

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32752>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32752

------- Additional Comments From sdeboy <at> iname.com  2005-11-02 16:06 -------
MDC properties were merged with logger repository properties, and when that was
done Ceki chose to support Strings as values in the LoggerRepository setProperty
method (and change the MDC implementation to match).

We could change the methods to use setProperty(String, Object) - we'd just need
to change the interface signature for both MDC and LoggerRepository.  

Since logger repository properties are new with 1.3, I don't think it's a problem.

Ceki may have stronger opinions about using strings as values, but since we can
do tostring on the object and push it on to the developer to provide a
reasonable toString, I don't think this is a big deal.

Scott

--

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Mark Womack | 2 Nov 23:01 2005
Picon

[RESULT] [VOTE] log4j 1.3 alpha 7 release

Just for some finality, the release of this alpha version was approved.  I will be moving it to the download areas tonight, signed, etc.

thanks,
-Mark

Mark Womack | 2 Nov 23:12 2005
Picon

Re: [VOTE] log4j 1.3 alpha 7 release

lazy approval is good for me.  Scott, can you put the change, with language, to a review and vote on the general list for the PMC members?

thanks,
-Mark

On 10/24/05, Scott Deboy <sdeboy <at> comotivsystems.com> wrote:
+1

I don't mind putting it up for a vote, but we could make it a lazy
approval vote.

Let's agree on something and get it in the 'Actions' section of the
bylaws.


-----Original Message-----
From: Yoav Shapira [mailto:yoavs <at> apache.org]
Sent: Monday, October 24, 2005 7:36 AM
To: Log4J Developers List
Subject: Re: [VOTE] log4j 1.3 alpha 7 release

Hi,
+1, and I also don't think we need a vote to release an alpha (or beta,
+or RC)
build, only a vote on declaring something stable.

Yoav

--- Jacob Kjome <hoju <at> visi.com> wrote:

> Quoting Mark Womack < mwomack <at> apache.org>:
>
> > This is vote to decide if the current build of log4j 1.3 alpha 7
> > should be released.  If accepted, the build located at:
> >
> > http://cvs.apache.org/builds/logging/log4j/log4j-1.3a7/
> >
> > would be moved to the release area, with the related signed
> > versions, and the related download pages would be updated
> > accordingly (PMC approval, of course).
> >
> > I am +1.
> >
>
> +1, although does an alpha really need a vote?
>
> Jake
>
> > -Mark
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe <at> logging.apache.org
> For additional commands, e-mail: log4j-dev-help <at> logging.apache.org
>
>


Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs <at> computer.org / www.yoavshapira.com

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe <at> logging.apache.org
For additional commands, e-mail: log4j-dev-help <at> logging.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe <at> logging.apache.org
For additional commands, e-mail: log4j-dev-help <at> logging.apache.org


alex | 3 Nov 11:11 2005
Picon

Re: CachingAppender

Elias, thanks for your response.

> It's a nice idea, but there's some code formatting and initialization
> things to clean up.  Also, there's some potential performance issues...

what "initialization things" do you mean? I know that initialization
(things I'm doing in initAppenders()) should be done in activateOptions()
but I noticed that I can't get the decorated appenders in
activateOptions(). :-((
I don't love to call initAppenders() every time doAppend() is called but I
found no other way. Give me a hint for any other solution.

> 
> Just as an example:
> 
>         protected void appendInternalMessage( Object msg, long timestamp
)
>         {
>                 if( msg != null && msg.toString().trim().length() > 0 )
>                 {
>                         // use message as pattern
>                         PatternLayout layout = new PatternLayout( 
msg.toString() );
> 
> Calling msg.toString() and creating a new PatternLayout per message
> seems a little costly.  It's also wrong (like, what if %C appeared in

You're right. I've changed that.

> your message?)

Don't see the issue if %C appears in the message. It should be possible to
use all the special characters of the PatternLayout in header and footer
lines (and they should be replaced). Using %C you're able to create a
header line like "Dumping cached events because of message initiated by
%C".

Do you think there's a chance to add the appender to the official log4j
stuff?

Regards,
Alex
Attachment (CachingAppender.java): application/octet-stream, 16 KiB
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe <at> logging.apache.org
For additional commands, e-mail: log4j-dev-help <at> logging.apache.org
fuse | 3 Nov 18:04 2005

Unreachable "expression" parameter in SMTPAppender


The class Javadoc for SMTPAppender mentions the expression parameter as a way to
affect the behaviour of the TriggeringEventEvaluator installed by SMTPAppender's
default constructor.

However, with no setExpression(String expression) method within SMTPAppender it
seems this option is unreachable from the DOMConfigurator.

Should the JavaDoc be updated and this reference removed, or should the code be
updated to support this option, or am I just misunderstanding this?

Thanks,

Nigel
bugzilla | 3 Nov 23:16 2005
Picon

DO NOT REPLY [Bug 37349] New: - DBAppender not working with jTDS driver

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37349>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37349

           Summary: DBAppender not working with jTDS driver
           Product: Log4j
           Version: 1.3alpha
          Platform: PC
               URL: http://sourceforge.net/forum/forum.php?thread_id=1377897
                    &forum_id=104389
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Appender
        AssignedTo: log4j-dev <at> logging.apache.org
        ReportedBy: gingming <at> hotmail.com

When using DBAppender with the jTDS driver, it gave the following error: 

java.sql.SQLException: No current row in the ResultSet. 
at net.sourceforge.jtds.jdbc.JtdsResultSet.getColumn(JtdsResultSet.java:269) 
at net.sourceforge.jtds.jdbc.JtdsResultSet.getInt(JtdsResultSet.java:630) 
at org.apache.log4j.db.DBAppender.append(DBAppender.java:226) 
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:239) 
at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:67)

at org.apache.log4j.Category.callAppenders(Category.java:219) 
at org.apache.log4j.Category.forcedLog(Category.java:588) 
at org.apache.log4j.Category.log(Category.java:1169) 
at org.apache.commons.logging.impl.Log4JLogger.info(Log4JLogger.java:135) 

The jTDS developer believe that it's a bug in DBAppender with the following comment:

Moving on to the error itself it's indeed caused by DBAppender. It tries to
retrieve auto generated keys although it didn't request them in the first place:
it calls prepareStatement(String) instead of prepareStatement(String, int),
which is needed if auto generated keys are to be retrieved. A second problem is
that it doesn't even check whether ResultSet.next() returned true or not and it
just goes for the value which isn't there. Here's the code in question: 

http://fisheye.cenqua.com/viewrep/jakarta/jakarta-log4j/src/java/org/apache/log4j/db/DBAppender.java?r=1.17&k=

For more information, please refer to:

http://sourceforge.net/forum/forum.php?thread_id=1377897&forum_id=104389

URL of jTDS: http://jtds.sourceforge.net/

--

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Mark Womack | 4 Nov 02:48 2005
Picon

Re: JBoss and deadlock issues

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 <eross <at> m-qube.com> 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: log4j-dev-unsubscribe <at> logging.apache.org
For additional commands, e-mail: log4j-dev-help <at> logging.apache.org


Mark Womack | 4 Nov 03:09 2005
Picon

Re: JBoss and deadlock issues

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 <mwomack <at> apache.org> 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 < eross <at> m-qube.com> 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: log4j-dev-unsubscribe <at> logging.apache.org
For additional commands, e-mail: log4j-dev-help <at> logging.apache.org



Paul Smith | 4 Nov 03:27 2005

Re: JBoss and deadlock issues

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 <mwomack <at> apache.org> 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 < eross <at> m-qube.com> 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: log4j-dev-unsubscribe <at> logging.apache.org
For additional commands, e-mail: log4j-dev-help <at> logging.apache.org




Attachment (smime.p7s): application/pkcs7-signature, 3372 bytes
Mark Womack | 4 Nov 03:38 2005
Picon

Re: JBoss and deadlock issues

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.

And I did find that the conversation on jboss went beyond the 21st.  It is an interesting read I highly recommend.

-Mark

On 11/3/05, Paul Smith <psmith <at> aconex.com> wrote:
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 < mwomack <at> apache.org> 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 < eross <at> m-qube.com> 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: log4j-dev-unsubscribe <at> logging.apache.org
For additional commands, e-mail: log4j-dev-help <at> logging.apache.org







Gmane