logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DeSantis, MJ Mark @ IS (7179)" <Mark.J.DeSan...@L-3com.com>
Subject RE: JmsAppender bug?
Date Fri, 03 Feb 2006 14:41:02 GMT
Thanks for the quick response, all. Sorry I was away from my email and
couldn't respond yesterday in a timely manner.

Curt, thanks for the bug tracking info. We are using cvs (at work here), not
subversion (unfortuately). Getting permission to set it up, learning it
enough to report the bug, could take an unjustifiable amount of time. So
over this weekend I'll do it at home and hopefully I can get something done
before Monday hits.

I understand now the call to super. Thanks for the explination. In our code
we just changed the super(false) call in the constructor to super(true)
which I see now is bad. I think your code of calling super.activateOptions()
inside the if statement will work for us. We will try it today, thanks.


-----Original Message-----
From: Curt Arnold [mailto:carnold@apache.org] 
Sent: Thursday, February 02, 2006 4:06 PM
To: Log4J Users List
Subject: Re: JmsAppender bug?

On Feb 2, 2006, at 3:35 PM, DeSantis, MJ Mark @ IS (7179) wrote:

> We got all the log4j code from the src directory that came with the 
> logging-log4j1.3-alpha7.zip file. I just looked at the svn trunk
> and the two
> bugs we found are still in it except that there is method wrapping the
> inOrder field now (checkEntryConditions()).

The checkEntryConditions was restored the the JMSAppender to fix a  
binary compatibility issue.  There was not additional work or testing  
that the appender actually worked.

> I would be happy to subimt a bug report how would I go about doing  
> that? I'm
> sort of a noob and don't really know what you mean by unified patch  
> (diff
> -u). But I could try - just give me some information to get started.

Reporting bugs: http://issues.apache.org/bugzilla.

Best thing to do is to check out the current source from Subversion,  
make changes to your local copy and then run "svn diff >  
mypatch.diff" and attach the file to the bug.

>> The second was was that in the JmsAppender constructor the call to  
>> the
>> super() AppenderSkeleton was set to false which would always make the
>> appender inactive and thus unusable.

The call to super(false) is intentional since the appender is in an  
unusable state at that time.  The log4j 1.3 branch changed the  
default behavior that appenders derived from AppenderSkeleton are  
created inactive and a subsequent call to  
AppenderSkeleton.activateOptions() is required to enable the  
appender.  JMSAppender.activateOptions() did not call its  
super.activateOptions() when properly configured.

What is really needed is some unit tests around this appender.   
Apparently, it has been doubly broken in log4j 1.3 for a long time.   
I did this patch from observation and haven't attempted to set up a  
test, let me know if gets you any further.

Index: src/java/org/apache/log4j/net/JMSAppender.java
--- src/java/org/apache/log4j/net/JMSAppender.java	(revision 374520)
+++ src/java/org/apache/log4j/net/JMSAppender.java	(working copy)
@@ -234,8 +234,9 @@
         "Error while activating options for appender named [" + name  
+ "].", e);

-    if (this.topicConnection != null && this.topicSession != null &&  
this.topicPublisher == null) {
+    if (this.topicConnection != null && this.topicSession != null &&  
this.topicPublisher != null) {
        inOrder = true;
+      super.activateOptions();
      } else {
        inOrder = false;
@@ -277,6 +278,7 @@
      topicPublisher = null;
      topicSession = null;
      topicConnection = null;
+    inOrder = false;

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message