date:20100531


On May 31, 2010, at 10:31 PM, Jacob Kjome wrote:

> I thought it might be useful to interject with some history about Log4j and
> ServletContext logging.  Please see this recent thread on the slf4j-user list 
> for
> some pertinent details explaining how this is actually possible today with 
> Log4j
> 1.2...
> 
> http://marc.info/?t=12735918324&r=1&w=2

Thanks for the context.  I guess I should subscribe to SLF4J User's - I only 
subscribe to the dev list.

FWIW, in SLF4J ILoggerFactory plays the same role as LoggerContext in my Log4J2 
API.  Logback handles different types of Contexts as described at 
http://logback.qos.ch/manual/loggingSeparation.html. My intention is to do 
something similar. However, neither SLF4J or Logback provide links to an 
external context as far as I am aware.

> 
> 
> Now that you are familiar with that, let's address the LoggerContext stuff.  I
> agree with Ralph's objections to Curt's proposal (though possibly not for the 
> same
> reasons).  However, I'm not necessarily in agreement with Ralph either.  
> First,
> some basic questions
> 
> Can there be only one LoggerContext as is implied by
> LogManager.setContext(LoggerContext)?  Why not support multiple contexts at 
> any
> given time?  And just because a context has been set, does that imply that the
> context itself logs (as opposed to merely providing some contextual 
> information)
> or that all logging should go to that context when it is set regardless of
> configured appenders?  And what if LogManager exists at the container level,
> meaning that Log4j is being shared by all apps?  We can't use the context of 
> one
> app for all apps, e.g., we can't be using a single webapp's ServletContext to 
> log
> for all apps.  The context should be scoped to the current Logger Repository, 
> not
> the classloader of the LogManager.

Another Jira issue to open. In 2.0 it needs to be possible to let every webapp 
have its own LoggerContext even though the Log4J code might be shared. Logback 
currently provides this functionality. Personally, I think this is one of the 
huge flaws in J2EE - that the components that are in the container are exposed 
to the webapps running in them, but I can't fix that.


> 
> In any case, isn't this what an Appender is for?  To me, unless a logging
> configuration specifies that logging information for a given logger ought to 
> go to
> an appender that directs logging to the servlet context, then it shouldn't go 
> to
> the servlet context regardless of any supplied context.  It should go to 
> whatever
> appender it is configured to go to.

In general, the approach you took makes sense. 

> 
> 
> Here are my requirements...
> 
> 1.  I would only agree with a context (zero or more) being able to be 
> supplied to
> a Logger method if it is made absolutely clear that just because a context is
> provided, does not imply that context will have any effect on logging, as it 
> would
> depend on whether the current configured appenders recognize, and make use 
> of, the
> context.  If an appender is assigned to the logger in question AND it 
> supports the
> provided context, then it would be utilized, otherwise not.  That said, I'm 
> not
> sure that it's worth the API pollution nor amount of confusion that this would
> inevitably create for users?

If it were then I would suggest that it be incorporated via a 
ContextAwareMessage, not an additional Object on the API.  This is similar to 
the problem I ran into with StructuredData, having Appenders have to run 
through all the parameters doing instanceof is a hack.

> 
> 2.  It MUST be possible to set the context in some other more general way.  
> Why?
> Because, in the case of a ServletContext, it is only available to application
> classes that participate in the servlet lifecycle, not general library 
> classes.
> All classes that log must be able to participate.
> 
> 3.  It must work for ANY number of Logger Repositories, not just the default 
> one.

I know what you mean, but in my version of 2.0 Logger Repositories don't exist. 
The LoggerContext contains the Map of all the loggers obtained by getLogger() 
and a reference to the configuration.  So the LoggerContext is equivalent to 
what I think you mean by Logger Repositories.

> 
> 
> The solution that Aleksei Valikov came up with, and I implemented in the Log4j
> sandbox [1][2], implements #2 and #3 above using plain old Log4j 1.2.  A few
> things could be improved upon, such as the static ServletContext registration
> concept and the requirement that appender configuration must provide the 
> context
> path.  Fallback to a non-context dependent appender would be beneficial as 
> well.
> The first two issues could be ameliorated by using a servlet Filter to 
> register a
> ThreadLocal for the request request/response lifecyle.  The last could be
> addressed simply by an update to the appender to allow for a fallback 
> appender to
> be configured.
> 
> 
> As has been shown, all of

Re: Improving log4j so it can easily be used with servlet logging

2010-05-31 Thread Jacob Kjome

I thought it might be useful to interject with some history about Log4j and
ServletContext logging. Please see this recent thread on the slf4j-user list
for
some pertinent details explaining how this is actually possible today with Log4j
1.2...

http://marc.info/?t=12735918324&r=1&w=2

Now that you are familiar with that, let's address the LoggerContext stuff. I
agree with Ralph's objections to Curt's proposal (though possibly not for the
same
reasons). However, I'm not necessarily in agreement with Ralph either. First,
some basic questions

Can there be only one LoggerContext as is implied by
LogManager.setContext(LoggerContext)? Why not support multiple contexts at any
given time? And just because a context has been set, does that imply that the
context itself logs (as opposed to merely providing some contextual information)
or that all logging should go to that context when it is set regardless of
configured appenders? And what if LogManager exists at the container level,
meaning that Log4j is being shared by all apps? We can't use the context of one
app for all apps, e.g., we can't be using a single webapp's ServletContext to
log
for all apps. The context should be scoped to the current Logger Repository,
not
the classloader of the LogManager.

In any case, isn't this what an Appender is for? To me, unless a logging
configuration specifies that logging information for a given logger ought to go
to
an appender that directs logging to the servlet context, then it shouldn't go to
the servlet context regardless of any supplied context. It should go to
whatever
appender it is configured to go to.

Here are my requirements...

1. I would only agree with a context (zero or more) being able to be supplied
to
a Logger method if it is made absolutely clear that just because a context is
provided, does not imply that context will have any effect on logging, as it
would
depend on whether the current configured appenders recognize, and make use of,
the
context. If an appender is assigned to the logger in question AND it supports
the
provided context, then it would be utilized, otherwise not. That said, I'm not
sure that it's worth the API pollution nor amount of confusion that this would
inevitably create for users?

2. It MUST be possible to set the context in some other more general way. Why?
Because, in the case of a ServletContext, it is only available to application
classes that participate in the servlet lifecycle, not general library classes.
All classes that log must be able to participate.

3. It must work for ANY number of Logger Repositories, not just the default
one.

The solution that Aleksei Valikov came up with, and I implemented in the Log4j
sandbox [1][2], implements #2 and #3 above using plain old Log4j 1.2. A few
things could be improved upon, such as the static ServletContext registration
concept and the requirement that appender configuration must provide the context
path. Fallback to a non-context dependent appender would be beneficial as well.
The first two issues could be ameliorated by using a servlet Filter to register
a
ThreadLocal for the request request/response lifecyle. The last could be
addressed simply by an update to the appender to allow for a fallback appender
to
be configured.

As has been shown, all of this can be done *without* the concept of an API-level
LoggerContext and, in fact, with the current production version of Log4j. I
strongly suggest that this LoggerContext stuff be thought through a bit more
before polluting the API with the concept. I'm not against the concept in
general. I just want to make sure that it isn't being implemented the wrong way
for the wrong reasons.

Thoughts?

[1]
http://svn.apache.org/repos/asf/logging/sandbox/log4j/log4j_sandbox/tags/LOG4J_SANDBOX_ALPHA3/src/java/org/apache/log4j/servlet/ServletContextLogAppender.java
[2]
http://svn.apache.org/repos/asf/logging/sandbox/log4j/log4j_sandbox/tags/LOG4J_SANDBOX_ALPHA3/src/java/org/apache/log4j/servlet/ServletContextLogAppenderListener.java

Jake

On 5/31/2010 5:56 PM, Ralph Goers wrote:
>
> On May 31, 2010, at 3:53 PM, Curt Arnold wrote:
>
>>
>> On May 31, 2010, at 3:28 PM, Thorbjørn Ravn Andersen wrote:
>>
>>> Den 30/05/10 23.12, Curt Arnold skrev:
I don't have this in code or in the JIRA, but I have mentioned in recent
threads the idea of a user-supplied context object in logging calls.
Currently log4j has a thread associated context (the MDC and NDC) and
there are JVM level context (line ending separator), but there is no
concept of a user-supplied context unless embedded in the message
parameter.
In this case, the logging call is operating in the "context" of the
servlet request, and you could do pass the servlet as the user-context
object. A servlet appender could check if the user context object was a
Servlet and if so delegate to its log method. We could also add patterns
for

svn commit: r949925 - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL: carnold/log4j2-api/src/main/java/org/apache/logging/core/ rgoers/log4j2-core/

2010-05-31 Thread carnold

Author: carnold
Date: Tue Jun  1 04:30:40 2010
New Revision: 949925

URL: http://svn.apache.org/viewvc?rev=949925&view=rev
Log:
Replace Filter.getLowerLimit/Upper with getThreshold

Added:

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/UnrecoverableLoggingException.java
Removed:

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/log4j2-core.iml
Modified:

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/AcceptAllFilter.java

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/ChainedFilter.java

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/DenyAllFilter.java

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/Filter.java

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/LevelRangeFilter.java

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/LoggingException.java

Modified: 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/AcceptAllFilter.java
URL: 
http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/AcceptAllFilter.java?rev=949925&r1=949924&r2=949925&view=diff
==
--- 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/AcceptAllFilter.java
 (original)
+++ 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/AcceptAllFilter.java
 Tue Jun  1 04:30:40 2010
@@ -63,14 +63,7 @@ public final class AcceptAllFilter imple
/**
 *  {...@inheritdoc}
  */
-   public int getLowerLimit() {
+   public int getThreshold() {
return Integer.MIN_VALUE;
}
-/**
- *  {...@inheritdoc}
-  */
-   public int getUpperLimit() {
-return Integer.MIN_VALUE;
-   }
-
 }

Modified: 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/ChainedFilter.java
URL: 
http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/ChainedFilter.java?rev=949925&r1=949924&r2=949925&view=diff
==
--- 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/ChainedFilter.java
 (original)
+++ 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/carnold/log4j2-api/src/main/java/org/apache/logging/core/ChainedFilter.java
 Tue Jun  1 04:30:40 2010
@@ -25,8 +25,7 @@ package org.apache.logging.core;
 public final class ChainedFilter implements Filter {
 private final Filter head;
 private final Filter tail;
-private final int lowerLimit;
-private final int upperLimit;
+private final int threshold;
 
 public ChainedFilter(Filter head, Filter tail) {
 if(head == null || tail == null) {
@@ -34,64 +33,69 @@ public final class ChainedFilter impleme
 }
 this.head = head;
 this.tail = tail;
-lowerLimit = Math.min(head.getLowerLimit(), tail.getLowerLimit());
-upperLimit = Math.max(head.getUpperLimit(), tail.getUpperLimit());
+threshold = Math.min(head.getThreshold(), tail.getThreshold());
 }
 /**
  *  {...@inheritdoc}
  */
 public Result filter(Level level) {
-Result headResult = head.filter(level);
-if(headResult != Filter.Result.NEUTRAL) {
-return headResult;
+if(level == null || level.getGenericValue() >= threshold) {
+Result headResult = head.filter(level);
+if(headResult != Filter.Result.NEUTRAL) {
+return headResult;
+}
+return tail.filter(level);
 }
-return tail.filter(level);
+return Result.DENY;
 }
 /**
  *  {...@inheritdoc}
  */
 public Result filter(Level level, Object userContext) {
-Result headResult = head.filter(level, userContext);
-if(headResult != Filter.Result.NEUTRAL) {
-return headResult;
+if(level == null || level.getGenericValue() >= threshold) {
+Result headResult = head.filter(level, userContext);
+if(headResult != Filter.Result.NEUTRAL) {
+return headResult;
+}
+return tail.filter(level, userContext);
 }
-return tail.filter(level, userContext);
+return Result.DENY;
 }
 
 /**
  *  {...@inheritdoc}
  */
 public Result filter(Level level, Object userCon

Re: Improving log4j so it can easily be used with servlet logging

On May 31, 2010, at 6:56 PM, Ralph Goers wrote:

> 
> On May 31, 2010, at 3:53 PM, Curt Arnold wrote:
> 
>> 
>> On May 31, 2010, at 3:28 PM, Thorbjørn Ravn Andersen wrote:
>> 
>>> Den 30/05/10 23.12, Curt Arnold skrev:
 I don't have this in code or in the JIRA, but I have mentioned in recent 
 threads the idea of a user-supplied context object in logging calls. 
 Currently log4j has a thread associated context (the MDC and NDC) and 
 there are JVM level context (line ending separator), but there is no 
 concept of a user-supplied context unless embedded in the message 
 parameter.
 In this case, the logging call is operating in the "context" of the 
 servlet request, and you could do pass the servlet as the user-context 
 object.  A servlet appender could check if the user context object was a 
 Servlet and if so delegate to its log method.  We could also add patterns 
 for %ipaddr, %ipport, etc, that would attempt to recognize the 
 user-context object and extract that info if it could recognize the type.
 
>>> I am unsure of what you describe. Could you write some pseudocode showing 
>>> what you mean?
>>> 
>> 
>> I'm working way below the client API at the moment, but the general idea is 
>> that in addition to MDC and NDC (aka the thread-associated context), the 
>> stack trace (aka the caller context), you can provide context with an 
>> explicit context parameter on the logging call. 
>> 
>> If the current logj4 API was extended to add user-supplied context, you'd 
>> have:
>> 
>> Logger.info(Object message, Throwable thrown, Object context);
> 
> I would object to this - see my other post.  I could tolerate this if it was 
> 
> Logger.into(Object message, Throwable thrown, Context context);
> 
> But since the Context is likely to have the same life expectancy as the 
> LoggerContext it makes more sense to just tie those together. 
> 

Being able to pass an arbitrary object through as the user context is pretty 
key to it being usable.  If you really wanted to pass an arbitrary context 
through, the naive way to do it would be:

logger.log(message, thrown, new ContextWrapper(arbitraryObject))

But you would take a hit on every call regardless of the threshold.

What would you suggest Context look like?


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

svn commit: r949908 - /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/test/java/org/apache/logging/log4j/SimpleLoggerContext.java

Author: rgoers
Date: Tue Jun  1 00:18:53 2010
New Revision: 949908

URL: http://svn.apache.org/viewvc?rev=949908&view=rev
Log:
Update test class with getExternalContext.

Modified:

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/test/java/org/apache/logging/log4j/SimpleLoggerContext.java

Modified: 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/test/java/org/apache/logging/log4j/SimpleLoggerContext.java
URL: 
http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/test/java/org/apache/logging/log4j/SimpleLoggerContext.java?rev=949908&r1=949907&r2=949908&view=diff
==
--- 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/test/java/org/apache/logging/log4j/SimpleLoggerContext.java
 (original)
+++ 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/test/java/org/apache/logging/log4j/SimpleLoggerContext.java
 Tue Jun  1 00:18:53 2010
@@ -31,4 +31,8 @@ public class SimpleLoggerContext impleme
 public boolean hasLogger(String name) {
 return false;
 }
+
+public Object getExternalContext() {
+return null;
+}
 }



-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

svn commit: r949907 - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: log4j2-api/src/main/java/org/apache/logging/log4j/ log4j2-api/src/main/java/org/apache/logging/log4j/spi/ log4j2-core/

Author: rgoers
Date: Tue Jun  1 00:13:35 2010
New Revision: 949907

URL: http://svn.apache.org/viewvc?rev=949907&view=rev
Log:
Add support for external contexts.

Added:

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/LogLevel.java

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/javaee/

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/javaee/ContextListener.java
Modified:

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/spi/LoggerContext.java
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/pom.xml

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java

Added: 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/LogLevel.java
URL: 
http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/LogLevel.java?rev=949907&view=auto
==
--- 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/LogLevel.java
 (added)
+++ 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/LogLevel.java
 Tue Jun  1 00:13:35 2010
@@ -0,0 +1,91 @@
+package org.apache.logging.log4j;
+
+import org.apache.logging.log4j.message.Message;
+
+/**
+ *
+ */
+public interface LogLevel {
+
+LogLevel toLevel(String sArg);
+
+/**
+ * Convert the string passed as argument to a level. If the
+ * conversion fails, then this method returns the value of
+ * defaultLevel.
+ */
+LogLevel toLevel(String sArg, Level defaultLevel);
+
+
+/**
+ * Log a message object with the current level
+ *
+ * @param message the message object to log.
+ */
+void log(Logger logger, String message);
+
+/**
+ * Log a message at the current level including the
+ * stack trace of the {...@link Throwable}t passed as 
parameter.
+
+ * @param message the message object to log.
+ * @param t   the exception to log, including its stack trace.
+ */
+void log(Logger logger, String message, Throwable t);
+
+/**
+ * Log a message object with the current level.
+ *
+ * @param message the message object to log.
+ */
+void log(Logger logger, Object message);
+
+/**
+ * Log a message at the current level including the
+ * stack trace of the {...@link Throwable}t passed as 
parameter.
+ *
+ * @param message the message object to log.
+ * @param t   the exception to log, including its stack trace.
+ */
+void log(Logger logger, Object message, Throwable t);
+
+/**
+ * Log a message with parameters at the current level.
+ *
+ * @param message the message to log.
+ * @param params  parameters to the message.
+ */
+void log(Logger logger, String message, Object... params);
+
+/**
+ * Log a message with the specific Marker at the current level.
+ *
+ * @param msg the message string to be logged
+ */
+void log(Logger logger, Message msg);
+
+/**
+ * Log a message with the specific Marker at the current level.
+ *
+ * @param msg the message string to be logged
+ * @param t   A Throwable or null.
+ */
+void log(Logger logger, Message msg, Throwable t);
+
+/**
+ * Log a message with the specific Marker at the current level.
+ *
+ * @param marker the marker data specific to this log statement
+ * @param msgthe message string to be logged
+ */
+void log(Logger logger, Marker marker, Message msg);
+
+/**
+ * Log a message with the specific Marker at the current level.
+ *
+ * @param marker the marker data specific to this log statement
+ * @param msgthe message string to be logged
+ * @param t  A Throwable or null.
+ */
+void log(Logger logger, Marker marker, Message msg, Throwable t);
+}

Modified: 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/spi/LoggerContext.java
URL: 
http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/spi/LoggerContext.java?rev=949907&r1=949906&r2=949907&view=diff
==
--- 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/spi/LoggerContext.java
 (original)
+++ 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/spi/LoggerContext.j

Re: Improving log4j so it can easily be used with servlet logging


On May 31, 2010, at 3:53 PM, Curt Arnold wrote:

> 
> On May 31, 2010, at 3:28 PM, Thorbjørn Ravn Andersen wrote:
> 
>> Den 30/05/10 23.12, Curt Arnold skrev:
>>> I don't have this in code or in the JIRA, but I have mentioned in recent 
>>> threads the idea of a user-supplied context object in logging calls. 
>>> Currently log4j has a thread associated context (the MDC and NDC) and there 
>>> are JVM level context (line ending separator), but there is no concept of a 
>>> user-supplied context unless embedded in the message parameter.
>>> In this case, the logging call is operating in the "context" of the servlet 
>>> request, and you could do pass the servlet as the user-context object.  A 
>>> servlet appender could check if the user context object was a Servlet and 
>>> if so delegate to its log method.  We could also add patterns for %ipaddr, 
>>> %ipport, etc, that would attempt to recognize the user-context object and 
>>> extract that info if it could recognize the type.
>>> 
>> I am unsure of what you describe. Could you write some pseudocode showing 
>> what you mean?
>> 
> 
> I'm working way below the client API at the moment, but the general idea is 
> that in addition to MDC and NDC (aka the thread-associated context), the 
> stack trace (aka the caller context), you can provide context with an 
> explicit context parameter on the logging call. 
> 
> If the current logj4 API was extended to add user-supplied context, you'd 
> have:
> 
> Logger.info(Object message, Throwable thrown, Object context);

I would object to this - see my other post.  I could tolerate this if it was 

Logger.into(Object message, Throwable thrown, Context context);

But since the Context is likely to have the same life expectancy as the 
LoggerContext it makes more sense to just tie those together. 

public class LoggerContextListener implements ServletContextListener {
  public void contextInitialized(ServletContextEvent event) {
LogManager.setContext(new 
ServletLoggerContext(event.getServletContext()));
  }

}

public class ServletLoggerContext extends LoggerContext {

private ServletContext context; 

public ServletLoggerContext(ServletContext context) {
super();
this.context = context;
}

public Object getExternalContext() {
return this.context;
}
}



Ralph


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Improving log4j so it can easily be used with servlet logging

On May 31, 2010, at 3:28 PM, Thorbjørn Ravn Andersen wrote:

> Den 30/05/10 23.12, Curt Arnold skrev:
>> I don't have this in code or in the JIRA, but I have mentioned in recent 
>> threads the idea of a user-supplied context object in logging calls. 
>> Currently log4j has a thread associated context (the MDC and NDC) and there 
>> are JVM level context (line ending separator), but there is no concept of a 
>> user-supplied context unless embedded in the message parameter.
>> In this case, the logging call is operating in the "context" of the servlet 
>> request, and you could do pass the servlet as the user-context object.  A 
>> servlet appender could check if the user context object was a Servlet and if 
>> so delegate to its log method.  We could also add patterns for %ipaddr, 
>> %ipport, etc, that would attempt to recognize the user-context object and 
>> extract that info if it could recognize the type.
>>   
> I am unsure of what you describe. Could you write some pseudocode showing 
> what you mean?
> 

I'm working way below the client API at the moment, but the general idea is 
that in addition to MDC and NDC (aka the thread-associated context), the stack 
trace (aka the caller context), you can provide context with an explicit 
context parameter on the logging call. 

If the current logj4 API was extended to add user-supplied context, you'd have:

Logger.info(Object message, Throwable thrown, Object context);

In the context of a Servlet, you could end up doing:

logger.info("Hello, World", null, this);
logger.info("Goodbye, World", null, this);

In the JSF snippet, it might be:

logger.info("Hello, World", null, getContext());

The context object would pass through the call stack and eventually get 
incorporated into the logging event.  You could then have a 
ServletContextAppender (or something like it do):

public void doAppend(LogRecord logEvent)
{
ServletContext context = null;
if(logEvent.getUserContext() instanceof ServletContext) {
context = (ServletContext) logEvent.getUserContext();
} else if(logEvent.getUserContext() instanceof Servlet) {
context = ((Servlet) logEvent.getUserContext()).getContext();
...
if(context != null) {
 ...
context.log(...);
}
}

We could likely have such a servlet appender in the default configuration since 
it would be innocuous unless a servlet context was passed.

It may not be the right answer for this problem, but I think it will be the 
right answer for a non-empty class of problems.

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: svn commit: r949590 - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: log4j2-api/src/main/java/org/apache/logging/log4j/ log4j2-core/ log4j2-core/src/main/java/org/apache/logging/log4j/


On May 31, 2010, at 1:23 PM, Curt Arnold wrote:

> 
> On May 31, 2010, at 1:57 PM, Ralph Goers wrote:
> 
>> 
>> On May 30, 2010, at 2:53 PM, carn...@apache.org wrote:
>> 
>>> Author: carnold
>>> Date: Sun May 30 21:53:24 2010
>>> New Revision: 949590
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=949590&view=rev
>>> Log:
>>> Code review comments
>>> 
>>> Added:
>>>  
>>> logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/log4j2-core.iml
>> 
>> Why did you check this in?  Interestingly, the one you committed is slightly 
>> different than mine.
>> 
>> Ralph
> 
> I think IntelliJ thought it needed to be added and then it got caught up with 
> things I did intend to commit.
> 
> Likely, both of ours were initially generated with "mvn idea:idea" and then 
> slightly diverged.
> 

Not sure. Sometimes I use mvn idea:idea, other times I let IntelliJ create the 
project from the root pom.xml. I think I used the latter method in this case.

Ralph


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Improving log4j so it can easily be used with servlet logging


On May 31, 2010, at 1:43 PM, Thorbjørn Ravn Andersen wrote:

> Den 30/05/10 21.34, Ralph Goers skrev:
>> Wouldn't it make more sense for the LoggerContext to have a reference to the 
>> ServletContext? The Appender could then do
>> 
>> if (getContext().getServletContext() != null) {
>>   getContext().getServletContext().log(event.getFormattedMessage());
>> }
>> 
>>   
> I do not know.  I am unfamiliar with what the LoggerContext provides.  Are 
> you suggesting that for each and every possible sub-context you will provide 
> a field in the LoggerContext?

No. It would probably make more sense to do what JSF does when it is running in 
a Portal:

Object obj = getContext().getExternalContext();

if (obj != null && obj instanceof ServletContext) {
((ServletContext) obj).log(event.getFormattedMessage());
}

One could also do:

if (getContext() instanceof LoggerServletContext) {
((LoggerServletContext) 
getContext()).getContext().log(event.getFormattedMessage());
}

in which case LoggerServletContext would extend LoggerContext and provide the 
field.

> 
>> Note that if the servlet adds its name to the MDC then all log records will 
>> have this available.  
>> 
>> To be honest though, I would have expected the desire would be to have the 
>> ServletContext's log methods route to Log4j, not the other way around.
>>   
> The reason is simple.  There is no guarantee that any J2EE container can or 
> will allow access to the filesystem.  Using the servlet log-method is the 
> _ONLY_ well-defined way to log things inside a J2EE container without needing 
> to make assumptions and manual configurations (remember the container doesn't 
> help).
> 
> Possible assumptions may be:
> 
> * I can access the file system.
> * Current working directory can be used (for writing or starting navigation)
> * The JVM provides environment variable which can be used to locate the 
> user.home of the operating system user running the JVM.
> * The JVM is allowed to write in user.home.
> 
> I like debug logs placed in the filesystem, but I also like to be able to 
> send log messages to the standard log mechanism.  The latter I cannot do 
> right now.
> 

OK. But just because you can't write to the FileSystem doesn't mean that 
writing via the ServletContext's log method is your only option. You can write 
to a database, syslog, SNMP, SMTP, etc. But yes, some configuration would be 
required to make that happen. Writing to the containers log file is sub-optimal 
in a lot of cases for various reasons such as; a) writing debug logs to the 
local file system can be a security risk, and b) multiple webapps may end up in 
a co-mingled log file.  While I understand your use case it is just one I would 
rarely, if ever, recommend.

Ralph


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Improving log4j so it can easily be used with servlet logging

2010-05-31 Thread Thorbjørn Ravn Andersen


Den 30/05/10 21.34, Ralph Goers skrev:

Wouldn't it make more sense for the LoggerContext to have a reference to the 
ServletContext? The Appender could then do

if (getContext().getServletContext() != null) {
   getContext().getServletContext().log(event.getFormattedMessage());
}

   
I do not know.  I am unfamiliar with what the LoggerContext provides.  
Are you suggesting that for each and every possible sub-context you will 
provide a field in the LoggerContext?



Note that if the servlet adds its name to the MDC then all log records will 
have this available.  

To be honest though, I would have expected the desire would be to have the 
ServletContext's log methods route to Log4j, not the other way around.
   
The reason is simple.  There is no guarantee that any J2EE container can 
or will allow access to the filesystem.  Using the servlet log-method is 
the _ONLY_ well-defined way to log things inside a J2EE container 
without needing to make assumptions and manual configurations (remember 
the container doesn't help).


Possible assumptions may be:

* I can access the file system.
* Current working directory can be used (for writing or starting navigation)
* The JVM provides environment variable which can be used to locate the 
user.home of the operating system user running the JVM.

* The JVM is allowed to write in user.home.

I like debug logs placed in the filesystem, but I also like to be able 
to send log messages to the standard log mechanism.  The latter I cannot 
do right now.


--
  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Improving log4j so it can easily be used with servlet logging

2010-05-31 Thread Thorbjørn Ravn Andersen


Den 30/05/10 23.12, Curt Arnold skrev:
I don't have this in code or in the JIRA, but I have mentioned in 
recent threads the idea of a user-supplied context object in logging 
calls. Currently log4j has a thread associated context (the MDC and 
NDC) and there are JVM level context (line ending separator), but 
there is no concept of a user-supplied context unless embedded in the 
message parameter.

In this case, the logging call is operating in the "context" of the servlet 
request, and you could do pass the servlet as the user-context object.  A servlet 
appender could check if the user context object was a Servlet and if so delegate to its 
log method.  We could also add patterns for %ipaddr, %ipport, etc, that would attempt to 
recognize the user-context object and extract that info if it could recognize the type.
   
I am unsure of what you describe. Could you write some pseudocode 
showing what you mean?


--
  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] Created: (LOG4J2-41) Extensible Log Level

2010-05-31 Thread Ralph Goers (JIRA)

Extensible Log Level


 Key: LOG4J2-41
 URL: https://issues.apache.org/jira/browse/LOG4J2-41
 Project: Log4j 2
  Issue Type: Improvement
  Components: API
Reporter: Ralph Goers


It is desirable to have the Level be an enum. However, it is also desirable to 
let users add new log levels. These goals are in opposition to each other since 
enum classes are final. In addition, adding new levels implies adding new 
methods to the Logger interface (or some counterpart to it). This would be 
unworkable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: svn commit: r949590 - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: log4j2-api/src/main/java/org/apache/logging/log4j/ log4j2-core/ log4j2-core/src/main/java/org/apache/logging/log4j/

On May 31, 2010, at 1:57 PM, Ralph Goers wrote:

> 
> On May 30, 2010, at 2:53 PM, carn...@apache.org wrote:
> 
>> Author: carnold
>> Date: Sun May 30 21:53:24 2010
>> New Revision: 949590
>> 
>> URL: http://svn.apache.org/viewvc?rev=949590&view=rev
>> Log:
>> Code review comments
>> 
>> Added:
>>   
>> logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/log4j2-core.iml
> 
> Why did you check this in?  Interestingly, the one you committed is slightly 
> different than mine.
> 
> Ralph

I think IntelliJ thought it needed to be added and then it got caught up with 
things I did intend to commit.

Likely, both of ours were initially generated with "mvn idea:idea" and then 
slightly diverged.
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

svn commit: r949854 - /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/Level.java

Author: rgoers
Date: Mon May 31 20:16:01 2010
New Revision: 949854

URL: http://svn.apache.org/viewvc?rev=949854&view=rev
Log:
Add @doubt comments

Modified:

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/Level.java

Modified: 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/Level.java
URL: 
http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/Level.java?rev=949854&r1=949853&r2=949854&view=diff
==
--- 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/Level.java
 (original)
+++ 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-api/src/main/java/org/apache/logging/log4j/Level.java
 Mon May 31 20:16:01 2010
@@ -40,6 +40,10 @@ package org.apache.logging.log4j;
  * or different logging API's (for example, the same level could be FINER with 
one converter and TRACE
  * with another. (RG) It's an Enum. All enums must provide the valueOf method. 
toLevel(String) is carried
  * over from 1.x.
+ *
+ * @doubt Curt makes valid points. I like this being an enum but I dislike 
that it doesn't support ALERT, SEVERE,
+ * NOTICE, SERIOUS, EMERGENCY, etc. Do we just add them? That multiples the 
number of methods in the Logger
+ * interface. I've heard suggestions that the log methods should be added to 
the Level. That would make sense.
  */
 public enum Level {
 OFF(0), FATAL(1), ERROR(2), WARN(3), INFO(4), DEBUG(5), TRACE(6), 
ALL(Integer.MAX_VALUE);
@@ -75,6 +79,10 @@ public enum Level {
 }
 
 /**
+ * @doubt I really dislike the "greaterOrEqual" and "lessOrEqual" methods. 
I can never remember whether
+ * the test compares this level to the passed in level or the other way 
around. As it stands, this
+ * method is not intuitive as the name is greaterOrEqual but the test it 
does is <=.
+ *
  * Compares the specified Level against this one.
  * @param level The level to check.
  * @return True if the passed Level is more general or the same as this 
Level.



-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

svn commit: r949837 - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core: Log4jLogEvent.java Logger.java

Author: rgoers
Date: Mon May 31 19:24:10 2010
New Revision: 949837

URL: http://svn.apache.org/viewvc?rev=949837&view=rev
Log:
Fix bug getting proper StackTraceElement. Make PrivateLoggerConfig immutable 
and make members private. Change comments on updateConfiguration to make sense.

Modified:

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Log4jLogEvent.java

logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Logger.java

Modified: 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Log4jLogEvent.java
URL: 
http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Log4jLogEvent.java?rev=949837&r1=949836&r2=949837&view=diff
==
--- 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Log4jLogEvent.java
 (original)
+++ 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Log4jLogEvent.java
 Mon May 31 19:24:10 2010
@@ -118,23 +118,8 @@ public class Log4jLogEvent implements Lo
 }
 
 /**
- * @doubt Not quite sure what is going on with the loop, but looks like it 
might
- * drop only the deepest call from the fully qualified class, not all 
of them.
- * (RG) The loop finds the FQCN and on the next iteration returns the 
StackTraceElement of
- * the caller of FQCN. Don't know what you mean by "not all of them" as it 
only returns
- * a single element.
- *
- *   Say that FQCN is "MySpecializedLogger" and the stack trace returned 
from getStackTrace is:
- *
- *   Log4jLogEvent.getSource
- *   MySpecializedLogger.log
- *   MySpecializedLogger.info
- *   ClientClass.doSomething
- *   ClientClass.main
- *
- *When walking the stack, next will be set to true  at 
MySpecializedLogger.log
- *and MySpecializerLogger.info will be returned (at least from code 
inspection).
- *
+ * Return the StackTraceElement for the caller. This will be the entry 
that occurs right
+ * before the first occurrence of FQCN as a class name.
  */
 public StackTraceElement getSource() {
 if (fqcnOfLogger == null) {
@@ -144,11 +129,15 @@ public class Log4jLogEvent implements Lo
 StackTraceElement[] stackTrace = 
Thread.currentThread().getStackTrace();
 boolean next = false;
 for (StackTraceElement element : stackTrace) {
+String className = element.getClassName();
 if (next) {
+if (fqcnOfLogger.equals(className)) {
+continue;
+}
 location = element;
 break;
 }
-String className = element.getClassName();
+
 if (fqcnOfLogger.equals(className)) {
 next = true;
 } else if (NOT_AVAIL.equals(className)) {

Modified: 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Logger.java
URL: 
http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Logger.java?rev=949837&r1=949836&r2=949837&view=diff
==
--- 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Logger.java
 (original)
+++ 
logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/Logger.java
 Mon May 31 19:24:10 2010
@@ -69,18 +69,14 @@ public class Logger extends AbstractLogg
 return new Logger(context, name);
 }
 
-/* @Override
-protected String getFQCN() {
-return FQCN;
-} */
-
 public LoggerContext getContext() {
 return context;
 }
 
 public synchronized void setLevel(Level level) {
-config.level = level;
-config.intLevel = level.intLevel();
+if (level != null) {
+config = new PrivateConfig(config, level);
+}
 }
 
 public Level getLevel() {
@@ -162,29 +158,27 @@ public class Logger extends AbstractLogg
 }
 
 /**
- * This method isn't synchronized to serialized updates to config. Rather, 
by doing this
- * it is guaranteed that all threads will see the update without having to 
declare the variable
- * volatile.
+ * There are two ways that could be used to guarantee all threads are 
aware of changes to
+ * config. 1. synchronize this method. Accessors don't need to be 
synchronized as Java wil
+ * treat all variables with

Re: svn commit: r949590 - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: log4j2-api/src/main/java/org/apache/logging/log4j/ log4j2-core/ log4j2-core/src/main/java/org/apache/logging/log4j/


On May 30, 2010, at 2:53 PM, carn...@apache.org wrote:

> Author: carnold
> Date: Sun May 30 21:53:24 2010
> New Revision: 949590
> 
> URL: http://svn.apache.org/viewvc?rev=949590&view=rev
> Log:
> Code review comments
> 
> Added:
>
> logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/log4j2-core.iml

Why did you check this in?  Interestingly, the one you committed is slightly 
different than mine.

Ralph


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: log4j2 sandbox

From that description our approaches have indeed been complimentary.  I saw 
problems in the fundamental core of Log4j and SLF4J/Logback that are in the 
API, configuration and filtering.  I've always considered the Appender and 
Layout concepts to be more or less OK, except how they were infringed upon by 
the core (i.e. callAppenders is synchronized).  The only significant impact my 
changes have made to those areas was to make the converters pluggable - 
PatternLayout does not need to be modified to add new ones.  The work done on 
EnhancedPatternLayout was essential to be able to do that.

I believe we both have agreement that the API should be separate from the 
implementation. I'm not sure we completely agree on what it should look like.  
To be honest, I'm still not completely happy with it as I'd like to see an 
annotation/AOP way of injecting logging wherever possible.

If there is a plan it is for Curt and me to continue working on our forks while 
reviewing each others code. Hopefully he will borrow from my code base and I 
from his.  I'm also hoping others will join in and contribute.

Ralph

On May 31, 2010, at 8:33 AM, Curt Arnold wrote:

> 
> On May 31, 2010, at 7:41 AM, Christian Grobmeier wrote:
> 
>> I just digged a little bit around the code. Besides the projects
>> mentioned below there is ralphs stuff. How is it planned to put it all
>> together?
>> 
> 
> You think we have a plan?
> 
> Ralph and I are going in two different, but hopefully eventually 
> complementary directions.
> 
> My tack was to start with the backend classes like layouts and appenders and 
> provide a framework which makes them independent of the logging API in use 
> and designed for concurrency.  I started in 2007 and 2008 with the pattern 
> layout.  That went dormant due to other demands and lack of participation.  
> There were a lot of ideas that I liked that were either in the code or in the 
> code that I was going to write next and I've been trying to mine the old 
> project and fill in gaps that had been rattling around in my mind to 
> hopefully come up with something reasonably fleshed out.
> 
> The approach with commons-logging and SLF4J was to unify on the API.  I was 
> taking the approach of enabling unification at the back end, basically, have 
> appenders that can process logging events originating from multiple API's.
> 
> Once the back end classes were established, they could be plugged into the 
> existing frameworks for testing and we could work on establishing a client 
> facing API designed with the same principles.
> 
> Ralph's approach has been broader, trying to design the whole framework 
> simultaneously.
> 
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: log4j2 sandbox

On May 31, 2010, at 7:41 AM, Christian Grobmeier wrote:

> I just digged a little bit around the code. Besides the projects
> mentioned below there is ralphs stuff. How is it planned to put it all
> together?
> 

You think we have a plan?

Ralph and I are going in two different, but hopefully eventually complementary 
directions.

My tack was to start with the backend classes like layouts and appenders and 
provide a framework which makes them independent of the logging API in use and 
designed for concurrency.  I started in 2007 and 2008 with the pattern layout.  
That went dormant due to other demands and lack of participation.  There were a 
lot of ideas that I liked that were either in the code or in the code that I 
was going to write next and I've been trying to mine the old project and fill 
in gaps that had been rattling around in my mind to hopefully come up with 
something reasonably fleshed out.

The approach with commons-logging and SLF4J was to unify on the API.  I was 
taking the approach of enabling unification at the back end, basically, have 
appenders that can process logging events originating from multiple API's.

Once the back end classes were established, they could be plugged into the 
existing frameworks for testing and we could work on establishing a client 
facing API designed with the same principles.

Ralph's approach has been broader, trying to design the whole framework 
simultaneously.

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: log4j2 sandbox