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);

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/ log4j2-core/src/main/java/org/apache/logging/log4j/c...

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
 <at>  <at>  -0,0 +1,91  <at>  <at> 
+package org.apache.logging.log4j;
+
+import org.apache.logging.log4j.message.Message;
+

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
 <at>  <at>  -31,4 +31,8  <at>  <at>  public class SimpleLoggerContext impleme
     public boolean hasLogger(String name) {
         return false;
     }
+
+    public Object getExternalContext() {
+        return null;
+    }
 }

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 

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

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
 <at>  <at>  -63,14 +63,7  <at>  <at>  public final class AcceptAllFilter imple
    /**

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

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=127359183200004&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...

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

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=127359183200004&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,

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

On Mon, 31 May 2010 22:48:25 -0700
  Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> 
> 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=127359183200004&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.
> 

Logback's Logger Context is equivalent to Log4j's Logger Repository, just as 
Logback's ContextSelector is equivalent to Log4j's RepositorySelector.  See 
another article written by Ceki back in 2002....

http://articles.qos.ch/sc.html

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

[jira] Created: (LOG4J2-42) Improving log4j so it can easily be used with servlet logging

Improving log4j so it can easily be used with servlet logging
-------------------------------------------------------------

                 Key: LOG4J2-42
                 URL: https://issues.apache.org/jira/browse/LOG4J2-42
             Project: Log4j 2
          Issue Type: Wish
          Components: API
            Reporter: Curt Arnold

On May 30, 2010, at 11:49 AM, Thorbjørn Ravn Andersen wrote:

There is one more thing that I would really like to see in log4j 2.0, namely the ability for a servlet to log to a
servlet container using log4j (and in slf4j too but that is a different story).   Currently that cannot be
done, because there is no way for the code asking for the logger to pass a "this" reference to the logging framework.

I would suggest that in log4j 2.0 the LoggerManager.getLogger() signature is changed to accept the class
(as now), and a varargs of Objects.  The objects are passed to the appender when needing to do the actual
logging, allowing a ServletLoggerAppender to look for any object extending GenericServlet and invoke
its log method.

For client code it would mean that the logger object was retreived similar to:

  Logger log = Logger.getLogger(this.getClass(), this);

We might even consider making the rule in log4j 2.0 that "the name of the logger is the full name of the class of
the first object"[2].  In that case we could make do with:

 Logger log = Logger.getLogger(this);

This would most likely also result in much other code being cleaner by allowing to drop the "getClass()" clause.

What do you think?

[1]
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/GenericServlet.html#log%28java.lang.String%29 

[2] For backwards compatability instances of Class should be treated slightly different :)

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

The follows at http://thread.gmane.org/gmane.comp.jakarta.log4j.devel/15576

--

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