Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44B2C0D4.9070705@ptc.com>
Date: Mon, 10 Jul 2006 16:04:20 -0500
From: Jess Holle <jessh@ptc.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Log4J Developers List <log4j-dev@logging.apache.org>
Subject: Re: JMX package
References: <2FB40470EBF3B949A838D34E06F12F3D2C5749@somme.ICSGLOBAL.local>
 <7.0.1.0.0.20060708143917.04b90b78@visi.com>
 <315BA7D5-65E8-42CF-BAC3-C1A970B8D61C@apache.org> <44B23C9B.5030403@ptc.com>
In-Reply-To: <44B23C9B.5030403@ptc.com>
Content-Type: multipart/alternative;
 boundary="------------020508080900090109030500"

--------------020508080900090109030500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jess Holle wrote:
> Curt Arnold wrote:
>> One things that seemed potentially interesting is to have a JMX 
>> appender that would allow log4j calls to generate JMX events.
> That would seem to be trivial.
>
> My approach has been to do any/all JMX notification in prior to and/or 
> in parallel to logging.  I do have JMX notification listeners that can 
> log the notification.
>
> To some degree, a log4j JMX notification appender seems like a 
> workaround for old code that really should be JMX instrumented and 
> doing notifications but which one does not own.  [For one thing, 
> though log4j allows the message to be an Object, which is very good, 
> the Object generally will not be a JMX open type (e.g. CompositeData 
> or TabularData), which JMX notification user data really should be -- 
> and thus it is probable that data structure loss will occur when a 
> general message Object is sent in a notification via logging -- at 
> least prior to Java 6 where more open-type conversion is automated.]  
> On the other hand, unless dealing in open source or doing consulting 
> your customers don't have your code, don't necessarily have the skill 
> to do the changes in any case, and may see needs for such 
> notifications that you cannot see initially.  For such cases, such an 
> appender seems like a very good thing.
>
> Dumb question along these lines: how does one reliably get the entire 
> MDC for a logging event, e.g. as a Map/Hashtable, from within an 
> appender?  I can see how to do everything else easily enough, but 
> that's one little nit.
I figured out the MDC stuff -- at least a reasonable if not foolproof 
approach -- and got everything working.  I did the code on company time, 
so I can't share it, but I can say that it is only about 400 lines total 
including the extra verbosity of shoving everything possible into the 
notification's user data as CompositeData and plenty of comments.

--
Jess Holle


--------------020508080900090109030500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jess Holle wrote:
<blockquote cite="mid44B23C9B.5030403@ptc.com" type="cite">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Curt Arnold wrote:<br>
  <blockquote cite="mid315BA7D5-65E8-42CF-BAC3-C1A970B8D61C@apache.org"
 type="cite">One things that seemed potentially interesting is to have
a JMX appender that would allow log4j calls to generate JMX events. <br>
  </blockquote>
That would seem to be trivial.<br>
  <br>
My approach has been to do any/all JMX notification in prior to and/or
in parallel to logging.&nbsp; I do have JMX notification listeners that can
log the notification.<br>
  <br>
To some degree, a log4j JMX notification appender seems like a
workaround for old code that really should be JMX instrumented and
doing notifications but which one does not own.&nbsp; [For one thing, though
log4j allows the message to be an Object, which is very good, the
Object generally will not be a JMX open type (e.g. CompositeData or
TabularData), which JMX notification user data really should be -- and
thus it is probable that data structure loss will occur when a general
message Object is sent in a notification via logging -- at least prior
to Java 6 where more open-type conversion is automated.]&nbsp; On the other
hand, unless dealing in open source or doing consulting your customers
don't have your code, don't necessarily have the skill to do the
changes in any case, and may see needs for such notifications that you
cannot see initially.&nbsp; For such cases, such an appender seems like a
very good thing.<br>
  <br>
Dumb question along these lines: how does one reliably get the entire
MDC for a logging event, e.g. as a Map/Hashtable, from within an
appender?&nbsp; I can see how to do everything else easily enough, but
that's one little nit.<br>
</blockquote>
I figured out the MDC stuff -- at least a reasonable if not foolproof
approach -- and got everything working.&nbsp; I did the code on company
time, so I can't share it, but I can say that it is only about 400
lines total including the extra verbosity of shoving everything
possible into the notification's user data as CompositeData and plenty
of comments.<br>
<br>
--<br>
Jess Holle<br>
<br>
<br>
</body>
</html>

--------------020508080900090109030500--