DO NOT REPLY [Bug 42151] - StackOverFlow in flush() method of LoggingOutputStream

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=42151





--- Additional Comments From [EMAIL PROTECTED]  2007-04-17 23:40 ---
Created an attachment (id=19985)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19985&action=view)
This is the file that contains the flush() method with the StackOverFlow


-- 
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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42151] - StackOverFlow in flush() method of LoggingOutputStream

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=42151





--- Additional Comments From [EMAIL PROTECTED]  2007-04-17 23:39 ---
Created an attachment (id=19984)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19984&action=view)
Appender being used.

This is the appender that we downloaded from the Log4j forums.

-- 
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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42151] - StackOverFlow in flush() method of LoggingOutputStream

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=42151





--- Additional Comments From [EMAIL PROTECTED]  2007-04-17 23:38 ---
Created an attachment (id=19983)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19983&action=view)
Exception trace

This is the exact exception trace that we see.

-- 
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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42151] New: - StackOverFlow in flush() method of LoggingOutputStream

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=42151

   Summary: StackOverFlow in flush() method of LoggingOutputStream
   Product: Log4j
   Version: 1.2
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P2
 Component: Appender
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: [EMAIL PROTECTED]


I am using Log4j as the logging utility for a J2EE (JDK version 1.4) 
application hosted on Weblogic server 8.1 sp2 running on Solaris 8.

The problem (StackOverFlow) occurs in the production environment when several 
jobs are run in parallel. The jobs start at 3:00 am and the error occurs 
between 9-10:30 am every day, but it is not associated with any job in 
paricular. We are unable to replicate this in dev, as the dev machines cannot 
handle the parallel processing of so many jobs. When we run the jobs one after 
another, there is no error.

The exact setup being used is as follows:
1) Each job is run using an instance of a class called WorkflowBo, which gains 
access to Log4j via its constructor in the following way:
  m_logger = Logger.getLogger(p_loggerName);
  e_logger = Logger.getLogger(p_loggerName + "_err");
2) We are using an appender that we downloaded off the Log4j forums called 
ArchivedDailyRollingFileAppender, as it zips up old log files. The file is 
available from:
http://mail-archives.apache.org/mod_mbox/logging-log4j-user/200405.mbox/%
[EMAIL PROTECTED]

The exact excexption that we see is pasted below. This stack keeps repeating 
several hundreds of times.
java.lang.StackOverflowError
at java.io.IOException.(IOException.java:40)
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at sun.nio.cs.StreamEncoder$CharsetSE.implWrite(StreamEncoder.java:395)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:136)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:146)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:204)
at java.io.Writer.write(Writer.java:126)
at org.apache.log4j.helpers.QuietWriter.write(QuietWriter.java:47)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301)
at com.csfb.fao.carat.util.file.ArchivedDailyRollingFileAppender.subAppend
(ArchivedDailyRollingFileAppender.java:375)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:159)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders
(AppenderAttachableImpl.java:65)
at org.apache.log4j.Category.callAppenders(Category.java:203)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:835)
at com.csfb.fao.carat.util.file.LoggingOutputStream.flush
(LoggingOutputStream.java:197)

at java.io.PrintStream.write(PrintStream.java:260)
at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at sun.nio.cs.StreamEncoder$CharsetSE.implWrite(StreamEncoder.java:395)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:136)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191)
at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:111)
at java.io.BufferedWriter.write(BufferedWriter.java:206)
at java.io.Writer.write(Writer.java:126)
at java.io.PrintStream.write(PrintStream.java:303)
at java.io.PrintStream.print(PrintStream.java:448)
at java.io.PrintStream.println(PrintStream.java:585)
at org.apache.log4j.helpers.LogLog.error(LogLog.java:142)
at org.apache.log4j.helpers.OnlyOnceErrorHandler.error
(OnlyOnceErrorHandler.java:77)
at org.apache.log4j.helpers.OnlyOnceErrorHandler.error
(OnlyOnceErrorHandler.java:67)
at org.apache.log4j.helpers.QuietWriter.write(QuietWriter.java:49)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301)
at com.csfb.fao.carat.util.file.ArchivedDailyRollingFileAppender.subAppend
(ArchivedDailyRollingFileAppender.java:375)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:159)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders
(AppenderAttachableImpl.java:65)
at org.apache.log4j.Category.callAppenders(Category.java:203)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:835)
at com.csfb.fao.carat.util.file.LoggingOutputStream.flush
(LoggingOutputStr

RE: [Patch review please] Further work for Receivers backport to 1.2

[Scott Deboy]

In DBAppender:
insertStatement.setLong(0, 0);
should be
insertStatement.setLong(1, 0);

Also, in CustomSQLDBReceiver:
Should
LoggingEvent event = new LoggingEvent(null,
eventLogger, timeStamp, levelImpl, message,
threadName,
throwableInfo,
ndc,
locationInfo,
properties);

be 

LoggingEvent event = new LoggingEvent(eventLogger.getName(),
eventLogger, timeStamp, levelImpl, message,
threadName,
throwableInfo,
ndc,
locationInfo,
properties);
?

In dbreceiverjob:
Should we pass a logger name instead of null in loggingevent constructor (same 
as above)?

Question: are we going to support event properties in the 1.2 stream?  Being 
able to populate properties from MDC, throwableinfo and NDC are all pretty 
important...would be nice if all of the receivers could use this functionality 
(multicastappender/receiver, etc).


Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR  97201

Telephone:  503.224.7496
Cell:   503.997.1367
Fax:503.222.0185

[EMAIL PROTECTED]

www.comotivsystems.com



-Original Message-
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: Tue 4/17/2007 9:40 PM
To: Log4J Developers List
Subject: Re: [Patch review please] Further work for Receivers backport to 1.2
 

On Apr 17, 2007, at 11:27 PM, Curt Arnold wrote:

>
> On Apr 17, 2007, at 10:42 PM, Paul Smith wrote:
>
>> Hi all,
>>
>> I've completed porting the remaining Receiver classes to the  
>> sandbox area.  The below patch is what I have locally, and taking  
>> the generated jar and adding it as a dependency to Chainsaw makes  
>> everything compile nicely.  I am not able to do any testing on  
>> this as yet, and figure a patch review is probably worthwhile at  
>> this stage.
>>
>> These are all baseline copies from the log4j trunk.  The DB* stuff  
>> needed more fiddling than the others.  I had to comment out all  
>> internal logging statements in the DBAppender because  
>> AppenderSkeleton in 1.2 does not provide that.  There is no  
>> concept of a sequence # either, so I munged that in the insert  
>> statement so that all the inserts have '0' as a sequence value.   
>> Given LoggingEvent in 1.2 doesn't have that anyway, I figure  
>> that's ok..
>>
>> Curty, Scott and others, any chance you could review this please  
>> before I check it in?
>>
>> (Note: I'll fix checkstyle issues later, I know there's tabs  
>> everywhere sorry)
>>
>
> Maybe you could fake out the getLogger() calls like
>
>   private static final class LogLogger {
>public void debug(final String msg) {
> LogLog.debug(msg);
>}
>   public void warn(final String msg) {
> LogLog.warn(msg);
>   }
>  public void error(final String msg, final Throwable ex) {
>LogLog.error(msg, ex);
> }
>  }
>  private static final LogLogger getLogger() {
> return new LogLogger();
>  }
>


or even better

  private static final LogLog getLogger() {
   return new LogLog();
  }


You could likely get style warnings that you shouldn't access static  
members using instance member syntax, but it should still work.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Patch review please] Further work for Receivers backport to 1.2

[Curt Arnold]

On Apr 17, 2007, at 11:27 PM, Curt Arnold wrote:



On Apr 17, 2007, at 10:42 PM, Paul Smith wrote:


Hi all,

I've completed porting the remaining Receiver classes to the  
sandbox area.  The below patch is what I have locally, and taking  
the generated jar and adding it as a dependency to Chainsaw makes  
everything compile nicely.  I am not able to do any testing on  
this as yet, and figure a patch review is probably worthwhile at  
this stage.


These are all baseline copies from the log4j trunk.  The DB* stuff  
needed more fiddling than the others.  I had to comment out all  
internal logging statements in the DBAppender because  
AppenderSkeleton in 1.2 does not provide that.  There is no  
concept of a sequence # either, so I munged that in the insert  
statement so that all the inserts have '0' as a sequence value.   
Given LoggingEvent in 1.2 doesn't have that anyway, I figure  
that's ok..


Curty, Scott and others, any chance you could review this please  
before I check it in?


(Note: I'll fix checkstyle issues later, I know there's tabs  
everywhere sorry)




Maybe you could fake out the getLogger() calls like

  private static final class LogLogger {
   public void debug(final String msg) {
LogLog.debug(msg);
   }
  public void warn(final String msg) {
LogLog.warn(msg);
  }
 public void error(final String msg, final Throwable ex) {
   LogLog.error(msg, ex);
}
 }
 private static final LogLogger getLogger() {
return new LogLogger();
 }




or even better

 private static final LogLog getLogger() {
  return new LogLog();
 }


You could likely get style warnings that you shouldn't access static  
members using instance member syntax, but it should still work.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Patch review please] Further work for Receivers backport to 1.2

[Curt Arnold]

On Apr 17, 2007, at 10:42 PM, Paul Smith wrote:


Hi all,

I've completed porting the remaining Receiver classes to the  
sandbox area.  The below patch is what I have locally, and taking  
the generated jar and adding it as a dependency to Chainsaw makes  
everything compile nicely.  I am not able to do any testing on this  
as yet, and figure a patch review is probably worthwhile at this  
stage.


These are all baseline copies from the log4j trunk.  The DB* stuff  
needed more fiddling than the others.  I had to comment out all  
internal logging statements in the DBAppender because  
AppenderSkeleton in 1.2 does not provide that.  There is no concept  
of a sequence # either, so I munged that in the insert statement so  
that all the inserts have '0' as a sequence value.  Given  
LoggingEvent in 1.2 doesn't have that anyway, I figure that's ok..


Curty, Scott and others, any chance you could review this please  
before I check it in?


(Note: I'll fix checkstyle issues later, I know there's tabs  
everywhere sorry)




Maybe you could fake out the getLogger() calls like

  private static final class LogLogger {
   public void debug(final String msg) {
LogLog.debug(msg);
   }
  public void warn(final String msg) {
LogLog.warn(msg);
  }
 public void error(final String msg, final Throwable ex) {
   LogLog.error(msg, ex);
}
 }
 private static final LogLogger getLogger() {
return new LogLogger();
 }

and access the "sequence number" through another private method:

private static long getSequenceNumber(final LoggingEvent event) {
 return 0;
}

That should allow the body of the functional methods to be unchanged  
between 1.3 and 1.2.x.  Only the kludge methods would need to change  
to switch between 1.3 and 1.2.


In DBReceiverJob.java, I'm unclear why you are doing:

Object msg = null;
...
msg = rs.getString(3);

instead of:

Object msg = rs.getString(3);

p.s. Only my Aunt Louise gets to call me Curty

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Chainsaw dependencies on log4j 1.3

[Paul Smith]

The WebStart model appears to use X.509 certificates which route  
back to a Certificate Authority, hence dealing with Thawte  
signatories.  Doesn't seem to be any bridge between the GPG model  
and the X.509 model which would allow us to use our existing GPG  
code signing keys.  The keys are tied to personal identities, so  
sharing signing keys as required by the log4net is inappropriate.   
It should not matter however if Paul signs one release and I sign  
the next (though my Thawte key is just the freemail variety).




Yep, it would not matter who signed the release.  ALL jars in the  
Webstart package must be signed with the same key though I think.   
Your freemail Thawte certificate is the same type as mine, the only  
difference is that I have had my "full name" verified by 2 other  
Thawte notaries.  For a while there, Chainsaw was signed just with  
'psmith < at > apache.org', but now it shows my full name.  That  
extra detail is probably irrelevant.  if there was an email address  
that could be 'controlled' by the Logging PMC, then perhaps we could  
sign it with a freemail certificate that had that email address in  
it.  Should a member get booted out or something else, the  
certificate could be revoked, and a new one generated by the PMC.   
One wouldn't be able to get a 'Full name' verified by a notary in  
this case though, since there isn't a real person to validate! :)   
The tricky thing is that Thawte freemail is all done online, so not  
sure how to control access to that online account by the PMC if/when  
a rogue member decided to get creative...


I'm getting dizzy and maybe can find some way to reconcile all  
this.  I think we have to have our primary distribution means a  
classic .tar.gz and .zip going through the standard release  
process.  Whether or how we make a WebStart version available after  
that is a separate issue.


I definitely think continuing to support the Webstart version is  
worthwhile, it makes upgrades for everyone really easy.  I'm  
obviously not tied to having it signed with my certificate, I just  
happened to be the first one to get one arranged and fight through  
all the stupid keysigning rubbish that Sun has placed on us.


Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Patch review please] Further work for Receivers backport to 1.2

[Paul Smith]

Hi all,

I've completed porting the remaining Receiver classes to the sandbox  
area.  The below patch is what I have locally, and taking the  
generated jar and adding it as a dependency to Chainsaw makes  
everything compile nicely.  I am not able to do any testing on this  
as yet, and figure a patch review is probably worthwhile at this stage.


These are all baseline copies from the log4j trunk.  The DB* stuff  
needed more fiddling than the others.  I had to comment out all  
internal logging statements in the DBAppender because  
AppenderSkeleton in 1.2 does not provide that.  There is no concept  
of a sequence # either, so I munged that in the insert statement so  
that all the inserts have '0' as a sequence value.  Given  
LoggingEvent in 1.2 doesn't have that anyway, I figure that's ok..


Curty, Scott and others, any chance you could review this please  
before I check it in?


(Note: I'll fix checkstyle issues later, I know there's tabs  
everywhere sorry)


Index: src/main/java/org/apache/log4j/db/DBAppender.java
===
--- src/main/java/org/apache/log4j/db/DBAppender.java   (revision 529843)
+++ src/main/java/org/apache/log4j/db/DBAppender.java   (working copy)
@@ -162,7 +162,7 @@
   }
   public void activateOptions() {
-getLogger().debug("DBAppender.activateOptions called");
+/*getLogger().debug("DBAppender.activateOptions called");*/
 if (connectionSource == null) {
   throw new IllegalStateException(
@@ -197,7 +197,7 @@
*  The connectionSource to set.
*/
   public void setConnectionSource(ConnectionSource connectionSource) {
-getLogger().debug("setConnectionSource called for DBAppender");
+/*getLogger().debug("setConnectionSource called for DBAppender");*/
 this.connectionSource = connectionSource;
   }
@@ -209,7 +209,10 @@

   PreparedStatement insertStatement =
   connection.prepareStatement(insertSQL);
-  insertStatement.setLong(1, event.getSequenceNumber());
+
+/*  insertStatement.setLong(1, event.getSequenceNumber());*/
+ insertStatement.setLong(0, 0);
+   
   insertStatement.setLong(2, event.getTimeStamp());
   insertStatement.setString(3, event.getRenderedMessage());
   insertStatement.setString(4, event.getLoggerName());
@@ -233,7 +236,7 @@

   int updateCount = insertStatement.executeUpdate();
   if (updateCount != 1) {
-  getLogger().warn("Failed to insert loggingEvent");
+/*  getLogger().warn("Failed to insert loggingEvent");*/
   }

   ResultSet rs = null;
@@ -250,7 +253,7 @@
   }
   throw ex;
   } catch(IllegalAccessException ex) {
-  getLogger().warn("IllegalAccessException invoking  
PreparedStatement.getGeneratedKeys", ex);
+/*  getLogger().warn("IllegalAccessException  
invoking PreparedStatement.getGeneratedKeys", ex);*/

   }
   }

@@ -314,7 +317,7 @@
   String[] strRep = event.getThrowableStrRep();

   if (strRep != null) {
-  getLogger().debug("Logging an exception");
+/*  getLogger().debug("Logging an exception");*/

   PreparedStatement insertExceptionStatement =
   connection.prepareStatement(insertExceptionSQL);
@@ -338,7 +341,7 @@

   connection.commit();
   } catch (Throwable sqle) {
-  getLogger().error("problem appending event", sqle);
+/*  getLogger().error("problem appending event", sqle);*/
   } finally {
   DBHelper.closeConnection(connection);
   }
Index: src/main/java/org/apache/log4j/db/CustomSQLDBReceiver.java
===
--- src/main/java/org/apache/log4j/db/CustomSQLDBReceiver.java	 
(revision 529843)
+++ src/main/java/org/apache/log4j/db/CustomSQLDBReceiver.java	 
(working copy)

@@ -398,19 +398,24 @@
 }
 Level levelImpl = Level.toLevel(level);
-LoggingEvent event = new LoggingEvent(
-eventLogger.getName(), eventLogger,  
levelImpl,

-message, null);
-event.setLocationInformation(new LocationInfo 
(fileName,

-className, methodName, lineNumber));
+
+
+   LocationInfo locationInfo = new 
LocationInfo(fileName,
+   className, methodName, lineNumber);
+   
+   ThrowableInformation throwableInfo =  
new ThrowableInformation(
+   exception);
+   
 properties.putAll(mdc);
-event.setTimeStamp(timeStamp);
-event.setThrowableInformation(new  
ThrowableInformation(

-   

Re: maven and jms

[Paul Smith]

ok, so I literally do just follow those directions.  Cool, just  
thought it was odd.  Thanks Curt.


On 18/04/2007, at 9:14 AM, Curt Arnold wrote:



On Apr 17, 2007, at 5:52 PM, Paul Smith wrote:

Ok, I tried adding the jms dependency to the receivers pom.xml,  
but try as I might to fight with the maven settings.xml I  
continually get this error:


Missing:
--
1) javax.jms:jms:jar:1.1

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=javax.jms -DartifactId=jms \
  -Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1) log4j:apache-log4j-receivers:jar:0.1-SNAPSHOT
2) javax.jms:jms:jar:1.1

--
1 required artifact is missing.

for artifact:
  log4j:apache-log4j-receivers:jar:0.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)


Here's the diff of the pom.xml, I copied this snippet from the  
log4j's pom.xml, assuming it would work..:





...


Is it just me?



Paul


A lot of Sun's stuff has licenses that preclude redistribution such  
as packing them into the Maven repo.  So there is a description of  
the resource, but you have to manually download the stuff from  
Sun's site and then run the install command to put it into your  
local repo.


JMS 1.1 can be downloaded from http://java.sun.com/products/jms/ 
docs.html




Paul Smith
Core Engineering Manager

Aconex
The easy way to save time and money on your project

696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200  Fax: +61 3 9240 0299
Email: [EMAIL PROTECTED]  www.aconex.com

This email and any attachments are intended solely for the addressee.  
The contents may be privileged, confidential and/or subject to  
copyright or other applicable law. No confidentiality or privilege is  
lost by an erroneous transmission. If you have received this e-mail  
in error, please let us know by reply e-mail and delete or destroy  
this mail and all copies. If you are not the intended recipient of  
this message you must not disseminate, copy or take any action in  
reliance on it. The sender takes no responsibility for the effect of  
this message upon the recipient's computer system.

Re: maven and jms

[Curt Arnold]

On Apr 17, 2007, at 5:52 PM, Paul Smith wrote:

Ok, I tried adding the jms dependency to the receivers pom.xml, but  
try as I might to fight with the maven settings.xml I continually  
get this error:


Missing:
--
1) javax.jms:jms:jar:1.1

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=javax.jms -DartifactId=jms \
  -Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1) log4j:apache-log4j-receivers:jar:0.1-SNAPSHOT
2) javax.jms:jms:jar:1.1

--
1 required artifact is missing.

for artifact:
  log4j:apache-log4j-receivers:jar:0.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)


Here's the diff of the pom.xml, I copied this snippet from the  
log4j's pom.xml, assuming it would work..:





...


Is it just me?



Paul


A lot of Sun's stuff has licenses that preclude redistribution such  
as packing them into the Maven repo.  So there is a description of  
the resource, but you have to manually download the stuff from Sun's  
site and then run the install command to put it into your local repo.


JMS 1.1 can be downloaded from http://java.sun.com/products/jms/ 
docs.html

maven and jms

[Paul Smith]

Ok, I tried adding the jms dependency to the receivers pom.xml, but  
try as I might to fight with the maven settings.xml I continually get  
this error:


Missing:
--
1) javax.jms:jms:jar:1.1

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=javax.jms -DartifactId=jms \
  -Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1) log4j:apache-log4j-receivers:jar:0.1-SNAPSHOT
2) javax.jms:jms:jar:1.1

--
1 required artifact is missing.

for artifact:
  log4j:apache-log4j-receivers:jar:0.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)


Here's the diff of the pom.xml, I copied this snippet from the  
log4j's pom.xml, assuming it would work..:


Paul-Smiths-Computer:/workspace/log4j-stuff/receivers paulsmith$ svn  
diff pom.xml

Index: pom.xml
===
--- pom.xml (revision 529792)
+++ pom.xml (working copy)
@@ -117,6 +117,11 @@
   oro
   2.0.8
 
+
+  javax.jms
+  jms
+  1.1
+
   
   
 


I also hunted in the maven repository stuff, and it appears this is  
valid:


http://mvnrepository.com/artifact/javax.jms/jms

Is it just me?



Paul

Re: Chainsaw dependencies on log4j 1.3

[Paul Smith]

On 17/04/2007, at 4:38 PM, Curt Arnold wrote:



On Apr 17, 2007, at 12:14 AM, Paul Smith wrote:

Curt, many thanks for your efforts to get this this far.  I've  
followed the below steps, and it's _almost_ working.


I think the Receivers module will need to have a copy of  
org.apache.log4j.varia.LogFilePatternReceiver as well.  I can do  
an svn copy over from the 1.3 tree, rebuild the receivers module  
and we should be on our way.




Okay, I didn't see a compile time dependency on it.

The pom.xml will need to be modified to add a dependency from  
receivers to expression-filter.


The code has a lot of style issues (including some tabs) and an old- 
style copyright notice.


The code would need to be modified to use the new LoggingEvent  
constructor.




This is now done, but I also see now that the following Receivers are  
missing from the receiver pack (not sure why I didn't see it before)


* JMSReceiver
* MulticastReceiver
* UDPReceiver
* XMLSocketReceiver

* also the org.apache.log4j.db package appears to be missing.

I think it's a simply matter of svn copy, I'll do that next and try  
it out.
Chainsaw looks like it still has old style source file headers  
around.  Those would need to be changed for any release.


I need to tweak the sandbox projects so they place copies of  
LICENSE and NOTICE in the generated jar files.


Thanks for fixing the source files.

Paul

svn commit: r529792 - in /logging/sandbox/log4j/receivers: pom.xml src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java

[psmith]

Author: psmith
Date: Tue Apr 17 15:19:31 2007
New Revision: 529792

URL: http://svn.apache.org/viewvc?view=rev&rev=529792
Log:
* Fixed up LoggingEvent constructor usage to comply with log4j 1.2.
* Changed pom.xml to reference expression-filter project due to the 
LogFilePatternRecevier dependency on Rule schtuff


Modified:
logging/sandbox/log4j/receivers/pom.xml

logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java

Modified: logging/sandbox/log4j/receivers/pom.xml
URL: 
http://svn.apache.org/viewvc/logging/sandbox/log4j/receivers/pom.xml?view=diff&rev=529792&r1=529791&r2=529792
==
--- logging/sandbox/log4j/receivers/pom.xml (original)
+++ logging/sandbox/log4j/receivers/pom.xml Tue Apr 17 15:19:31 2007
@@ -108,6 +108,11 @@
   0.1-SNAPSHOT
 
 
+  log4j
+  apache-log4j-expression-filter
+  0.1-SNAPSHOT
+
+
   oro
   oro
   2.0.8

Modified: 
logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java
URL: 
http://svn.apache.org/viewvc/logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java?view=diff&rev=529792&r1=529791&r2=529792
==
--- 
logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java
 (original)
+++ 
logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java
 Tue Apr 17 15:19:31 2007
@@ -755,16 +755,14 @@
   info = LocationInfo.NA_LOCATION_INFO;
 }
 
-LoggingEvent event = new LoggingEvent();
-event.setLogger(logger);
-event.setTimeStamp(timeStamp);
-event.setLevel(levelImpl);
-event.setThreadName(threadName);
-event.setMessage(message);
-event.setThrowableInformation(new ThrowableInformation(exception));
-event.setLocationInformation(info);
-event.setNDC(ndc);
-event.setProperties(properties);
+LoggingEvent event = new LoggingEvent(null,
+logger, timeStamp, levelImpl, message,
+threadName,
+new ThrowableInformation(exception),
+ndc,
+info,
+properties);
+
 return event;
   }
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r529789 - /logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiverBeanInfo.java

[psmith]

Author: psmith
Date: Tue Apr 17 15:10:49 2007
New Revision: 529789

URL: http://svn.apache.org/viewvc?view=rev&rev=529789
Log:
Coping log4j trunk (1.3) version of LogFilePatternReceiverBeanInfo.java over to 
sandbox receiver area in readiness
for combining with Chainsaw.


Added:

logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiverBeanInfo.java
  - copied unchanged from r529788, 
logging/log4j/trunk/src/java/org/apache/log4j/varia/LogFilePatternReceiverBeanInfo.java


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r529788 - /logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java

[psmith]

Author: psmith
Date: Tue Apr 17 15:09:54 2007
New Revision: 529788

URL: http://svn.apache.org/viewvc?view=rev&rev=529788
Log:
Coping log4j trunk (1.3) version of LogFilePatternReceiver.java over to sandbox 
receiver area in readiness
for combining with Chainsaw.


Added:

logging/sandbox/log4j/receivers/src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java
  - copied unchanged from r529787, 
logging/log4j/trunk/src/java/org/apache/log4j/varia/LogFilePatternReceiver.java


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: GSOC: Congratulations Isuru (?)

[Isuru Suriarachchi]

Hi Paul and Scott,

Yes you are correct. My project has been selected as a GSoC project.
Thanks very much for your help so far. I think I'll need more help
when the project will be started. :-)
Coding will be started on 28th of May according to the GSoC time line.
These days we are on a short vacation and just after that I'll start
working on initial research stuff. Me too looking forward to complete
the project successfuly.

Thanks,
~Isuru


On 4/17/07, Paul Smith <[EMAIL PROTECTED]> wrote:

Unless I've misread something on the Google groups, Isuru
Suriarachchi and his 'Adding Functionality and Usability Improvements
to Chainsaw' project has been accepted as a GSOC project.  (it has,
at least been marked as 'slotted'.  Not exactly sure what that means)

If this is the case; Congratulations!  Looking forward to working
with you on this Isuru!

Paul


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Chainsaw dependencies on log4j 1.3

[Curt Arnold]

On Apr 17, 2007, at 5:27 AM, Paul Smith wrote:



The ant build.xml can has a 'webstart-dist' target and an 'iOrb'  
type target.  They generate and sign the jar files (it prompts  
you for a local keystore and certificate passwords during the  
signing process; I have my thawte certificate loaded in a  
keystore locally).  I think I had a target that uploads those  
signed stuff to the area where the Webstart bundle is kept, but  
due to symlink weirdness with Webstart, there's still a bit of  
hand moving of files around during the deployment.




log4net requires signed assemblies and until recently only Nicko  
was able to produce them.  He has recently placed an encrypted  
signing key in the SVN so that Ron or I can also produce builds of  
log4net.  Would we'd want to do the same type of thing for Chainsaw?




The main problem here is that the signature being signed with is my  
own personal one containing my @apache.org email address.  To get  
the email certificate properly certified, I had to get 2 Thawte  
signatories to meet me in person and check documentation.  I'm not  
sure how one gets around that for a generic 'log4j' certificate.   
I'm not sure I'd like to upload my signature that anyone could sign  
it with.


Having said that, if we can work out how we can generate a  
certificate that all the logging services people can use, I'd vote  
for that.  Can you explain exactly how the certificate was  
generated for log4net?


The public/private key pair was (most likely) generated by Nicko  
using the Strong Name tool (sn.exe) before log4cxx moved to Apache.   
There is no web-of-trust or other third-party validation for the  
public key and the key is not explicitly tied to a person or entity.   
Any change in the key used to sign the assembly would however result  
in the new assembly not being recognized as an acceptable replacement  
for the old assembly, so drop-in replacement requires the same key be  
used regardless of who builds the package.  However, you don't just  
want anyone having access to the key or spoofed implementations can  
get in the wild and would be assumed to be legitimate.  The private  
key is in the SVN but encrypted so it can be decrypted using Nicko,  
Ron and my GPG private key.  Any one of the three of us can add  
additional individuals who can decrypt the file.


Different GPG keys can be used to sign ASF releases and the keys are  
tied to a particular individual.  It doesn't matter who signs the  
release, just that the validity of the key can be confirmed by the  
web of trust.  So Mark could sign one release of log4j and I could  
sign the next.  If someone cares, they could check that Mark and I  
have signed the others keys, so our identities are equally trustworthy.


The WebStart model appears to use X.509 certificates which route back  
to a Certificate Authority, hence dealing with Thawte signatories.   
Doesn't seem to be any bridge between the GPG model and the X.509  
model which would allow us to use our existing GPG code signing  
keys.  The keys are tied to personal identities, so sharing signing  
keys as required by the log4net is inappropriate.  It should not  
matter however if Paul signs one release and I sign the next (though  
my Thawte key is just the freemail variety).


I'm getting dizzy and maybe can find some way to reconcile all this.   
I think we have to have our primary distribution means a  
classic .tar.gz and .zip going through the standard release process.   
Whether or how we make a WebStart version available after that is a  
separate issue.







I'm going to sleep now.  I may take a run at  
LogFilePatternReceiver tomorrow unless you want to take it.




I thought you were going to sleep!  Are you still in US Central TZ?



Still here in Houston.  Was a late night.








I've got the source file change tool down, so I'll take a pass at  
applying the tool to the chainsaw code base tomorrow unless  
someone calls me off (for example, if you have a lot of  
uncommitted changes).


Nothing local changed at all, save for the application of that  
patch you sent to change the log4j 1.3->1.2 dependency, which can  
be easily redone if need be.


Paul




Will commit shortly.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40944] - PropertyConfigurator.configure( URL ) does not close the resource stream

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40944


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-04-17 08:44 ---
*** Bug 42148 has been marked as a duplicate of this bug. ***

-- 
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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42148] New: - PropertyConfigurator.configure() does not close properties file

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=42148

   Summary: PropertyConfigurator.configure() does not close
properties file
   Product: Log4j
   Version: 1.2
  Platform: All
OS/Version: Windows XP
Status: NEW
  Severity: blocker
  Priority: P1
 Component: Configurator
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: [EMAIL PROTECTED]


We have a webapp that must be able to start logging during production.

Our solution is to start a timer thread from its ContextListener that regularly 
re-initializes the configuration from a log4j.properties file:

   LogManager.resetConfiguration();
  ClassLoader cl = this.getClass().getClassLoader();
  URL log4jPropsUrl = cl.getResource("log4j.properties");
  if (log4jPropsUrl != null)
 PropertyConfigurator.configure(log4jPropsUrl);
  else
 log.warn("log4j properties not found");

However, this locks the log4j.properties file, located in the webapp directory, 
so that a hot redeploy fails; Tomcat can't delete log4j.properties since it is 
locked. That is a show-stopper for us.

I have checked the source code of PropertyConfigurator, and think I have found 
the bug. The method doConfigure calls

   props.load(configUrl.openStream());

but it does not call close() on the resulting InputStream. It must be closed, 
or the file will be locked, at least on Windows. A fix may look like:

  InputStream is = configUrl.openStream();
  props.load(is);
  is.close();

We have encountered serveral other problems with files locked by log4j, but 
they are harder to track down. Searching the web also turns up several 
frustrations with files unnecessarily locked by log4j. It would therefore 
probably be a very good idea to search the log4j source code for similar 
constructs elsewhere and add close() wherever necessary.

-- 
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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42148] - PropertyConfigurator.configure() does not close properties file

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=42148


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2007-04-17 08:44 ---
This looks exactly like bug 40944 which is fixed in the SVN.  The fix was in 
the first release candidate for 
log4j 1.2.15 (currently at 
http://people.apache.org/builds/logging/log4j/1.2.15/) which failed to be 
released due to lack of sufficient votes.  Please check if that takes care of 
your observed problem.

*** This bug has been marked as a duplicate of 40944 ***

-- 
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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

GSOC: Congratulations Isuru (?)

[Paul Smith]

Unless I've misread something on the Google groups, Isuru  
Suriarachchi and his 'Adding Functionality and Usability Improvements  
to Chainsaw' project has been accepted as a GSOC project.  (it has,  
at least been marked as 'slotted'.  Not exactly sure what that means)


If this is the case; Congratulations!  Looking forward to working  
with you on this Isuru!


Paul

Re: Chainsaw dependencies on log4j 1.3

[Paul Smith]

The ant build.xml can has a 'webstart-dist' target and an 'iOrb'  
type target.  They generate and sign the jar files (it prompts you  
for a local keystore and certificate passwords during the signing  
process; I have my thawte certificate loaded in a keystore  
locally).  I think I had a target that uploads those signed stuff  
to the area where the Webstart bundle is kept, but due to symlink  
weirdness with Webstart, there's still a bit of hand moving of  
files around during the deployment.




log4net requires signed assemblies and until recently only Nicko  
was able to produce them.  He has recently placed an encrypted  
signing key in the SVN so that Ron or I can also produce builds of  
log4net.  Would we'd want to do the same type of thing for Chainsaw?




The main problem here is that the signature being signed with is my  
own personal one containing my @apache.org email address.  To get the  
email certificate properly certified, I had to get 2 Thawte  
signatories to meet me in person and check documentation.  I'm not  
sure how one gets around that for a generic 'log4j' certificate.  I'm  
not sure I'd like to upload my signature that anyone could sign it with.


Having said that, if we can work out how we can generate a  
certificate that all the logging services people can use, I'd vote  
for that.  Can you explain exactly how the certificate was generated  
for log4net?




I'm going to sleep now.  I may take a run at  
LogFilePatternReceiver tomorrow unless you want to take it.




I thought you were going to sleep!  Are you still in US Central TZ?







I've got the source file change tool down, so I'll take a pass at  
applying the tool to the chainsaw code base tomorrow unless someone  
calls me off (for example, if you have a lot of uncommitted changes).


Nothing local changed at all, save for the application of that patch  
you sent to change the log4j 1.3->1.2 dependency, which can be easily  
redone if need be.


Paul




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Chainsaw dependencies on log4j 1.3

[Curt Arnold]

On Apr 17, 2007, at 1:55 AM, Paul Smith wrote:



On 17/04/2007, at 4:38 PM, Curt Arnold wrote:



On Apr 17, 2007, at 12:14 AM, Paul Smith wrote:

Curt, many thanks for your efforts to get this this far.  I've  
followed the below steps, and it's _almost_ working.


I think the Receivers module will need to have a copy of  
org.apache.log4j.varia.LogFilePatternReceiver as well.  I can do  
an svn copy over from the 1.3 tree, rebuild the receivers module  
and we should be on our way.




Okay, I didn't see a compile time dependency on it.

The pom.xml will need to be modified to add a dependency from  
receivers to expression-filter.


The code has a lot of style issues (including some tabs) and an  
old-style copyright notice.




Yes, but Chainsaw did have those before, so I'm not fussing over  
the check style issues just yet.  The copyright ones are probably a  
higher priority given the legalese of it all.  I tried using that  
license-fixy script with no success before, but perhaps I was just  
being dumb.  I'd like to get Chainsaw built and running with 1.2.15  
before I tackle that.




I had wanted to get the style issues out before branching off from  
the 1.3 trunk so we could compare the trunk with sandbox and not have  
spurious formatting issues.  However, it looks like  
LogFilePatternReceiver can be identical in both the sandbox and  
trunk, so the order is not as important as I thought it would be.



The code would need to be modified to use the new LoggingEvent  
constructor.



Yep, I'll do that when I've got that copied over.


It is all yours.







I'm pretty much in the dark on the Chainsaw build and release  
process and that is likely to need to change.


The ant build.xml can has a 'webstart-dist' target and an 'iOrb'  
type target.  They generate and sign the jar files (it prompts you  
for a local keystore and certificate passwords during the signing  
process; I have my thawte certificate loaded in a keystore  
locally).  I think I had a target that uploads those signed stuff  
to the area where the Webstart bundle is kept, but due to symlink  
weirdness with Webstart, there's still a bit of hand moving of  
files around during the deployment.




log4net requires signed assemblies and until recently only Nicko was  
able to produce them.  He has recently placed an encrypted signing  
key in the SVN so that Ron or I can also produce builds of log4net.   
Would we'd want to do the same type of thing for Chainsaw?






Any thoughts on potentially Mavenizing Chainsaw?


I have to admit, I'm no big fan of Maven.  Mostly because I don't  
use it, nor really understand it's benefit over ant.  If you could  
think of why switching to Maven would be a good thing for Chainsaw,  
then I'm all ears, but the current process does work, and there are  
plenty of other things to do in Chainsaw ahead of that, IHMO.


You don't have to go collect all the dependencies, Maven can download  
them from ibiblio.  Plus you get a lot of site generation stuff for  
free.  If the build process is pretty simple, it is pretty simple to  
adapt it to Maven (and still support the Ant builds if you want to).   
It is not essential, but moving things around to conform with the  
standard project directory structure is a better long term solution  
than overriding Maven's.






A Chainsaw release would require another pass at a log4j 1.2.15  
release and some resolution to the home permanent of component,  
expression-filter and receivers.  component and receivers could be  
merged and/or made a subproject of Chainsaw.  I think expression- 
filters is worthwhile as a log4j 1.2 companion.  If we were to do  
expression-filters as a companion, I'd like to have pattern-layout  
ready about the same time.




I think bundling Receivers with Chainsaw will hide the usefulness  
of them to a broader audience.  I'm happy for them to be standalone  
additional packages like they are now.




Okay.



I'm going to sleep now.  I may take a run at  
LogFilePatternReceiver tomorrow unless you want to take it.




My days seem to fly by so quickly.  I'm trying desperately to gain  
control over time so I can get my hands dirty again.  I'm happy to  
take on the LogFilePatternReceiver.  If you have more knowledge of  
the source header fixy script, it would be well appreciated,  
otherwise I'll tackle that afterwards.


Please take LogFilePatternReceiver.

I've got the source file change tool down, so I'll take a pass at  
applying the tool to the chainsaw code base tomorrow unless someone  
calls me off (for example, if you have a lot of uncommitted changes).

Re: "Compelling Reasons to adopt log4j2"

[Curt Arnold]

On Apr 17, 2007, at 1:16 AM, Paul Smith wrote:

I got stuck, and all I can think of are these.  Other people may  
want to look at this and think about what might compel them to  
switch to log4j2 (when we get there.. :) )


Compelling Reasons for a log4j2 adoption

* Ease of migration/Drop in replacement for log4j 1.2 - If we do  
not meet this fundamental goal, I seriously doubt we'll ever gain  
traction.  We should be free from the log4j1.2 design, but we  
should begin early to ensure that the core design can be easily  
shimmed with a log4j2-1.2compatibility.jar or equivalent.


Not drop-in in the sense that you should feel free to take your  
production app and replace log4j 1.2 with log4j 2.0+shim without  
testing, but reasonable expectation that most mainstream uses can  
work with the shim.




* Finer grained synchronization - log4j1.2 has a weakness in it's  
synchronization mechanism that can cause problems in high load  
situations.   In it's earlier years this was never a problem, but  
more and more people hit these bottlenecks.


Yep



* Simplicity of management - 1.2 has a nice and easy .properties  
and .xml configuration mechanism but lacks finer grained runtime  
management controls. The jmx support in 1.2 is rather weak.




Plus Spring and other IoC management.  You should be able to  
configure log4j with the same config system that the rest of your app  
uses, at least in certain configs (aka not log4j 1.2 shim).


* Advanced Context logging - go beyond MDC and NDC to domains/ 
markers and other concepts.  Provide advanced tools to easily  
correlate logging events together for analysis.


Good area for experimentation, particularly when we look at the  
native log4j 2.0 logging API.  Don't think it affects the back-end  
design significantly.




* Locale-based logging - not everyone speaks English, or a single  
language.  Applications written for other countries may wish to  
deploy with bundles for logging messages.  The var-args support in  
Java 5 makes this one easy-peasy.  It also can limit the cost of  
logging String concatenation and remove the ugly code "if 
(LOG.isDebugEnabled())".  If the LOG.debug(...) statement can take  
var-args, then there is no overhead of string construction until  
the actual point you know you have to append something.




Localization can be handed either at the API end by resource bundles  
and parameters or at the appender end by translation (I discussed  
that approach a couple of years ago in the Enterprise Logging threads  
here and in commons-logging).  I think likely we should support  
both.  Since the java.util.logging supports resource bundle logging,  
we'd likely be in a good position if we design for interoperability  
with java.util.logging.  A translating layout could implemented in  
log4j 1.2.x, so I don't think it adds any design constraints.


If the "ugly code" concern is strictly formatting and not  
localization, then the formatter sandbox project can address that now  
as a log4j 1.2 companion.



* Small core module size - not one big uber jar (people are funny  
about large jars) - a somewhat weak argument, but you'd be  
surprised...





My favorites are:

java.util.logging interoperability.  Discussed earlier.

Designed for Java 5 and later

Better error handling and diagnostics.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]