Re: activateOptions()

[Anders Kristensen]

Yes, it's to deal with the cases where two or more parameters are inter
dependent. Say, a hostname and a port number for a network based
appender.

Anders

Christopher Randall wrote:
> 
> Can somebody please explain to me the design idea behind
> activateOptions()? If I call setFile(), why do I then need to call
> activateOptions()? It seems redundant and unnecessary to have this,
> unless ofcouse you purposely want to have transactions.
> 
> Are you trying to achieve transactional integrity by applying all the
> modified options at one time?
> 
> Thanks for the explanation,
> Chris
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Logging to multiple files

[Anders Kristensen]

It may be worth noting that version 2.3 of the Servlet API specifies
that apps run in a ClassLoader environment where they don't inherit
libraries from parents and don't share code with other apps. Each app
can incalude it's own copy of log4j and have it's own configuration,
completely independent of any other application.

Anders

Chris Barlock wrote:
> 
> Well, you already know about log4j.  Here are a few others of which I'm
> aware:
> 
> Logging Toolkit for Java:
> http://www.alphaworks.ibm.com/tech/loggingtoolkit4j
> JLogger:  http://www.javelinsoft.com/jlogger/
> LogKit:  http://jakarta.apache.org/avalon/logkit/index.html
> AutoTrace (not free):
> http://www.tkg.com/products/autotrace/documentation.html
> JLog:  http://www.jtrack.com/
> 
> Chris
> 
> Tivoli Systems
> Research Triangle Park, NC
> (919) 224-2240
> Internet:  [EMAIL PROTECTED]
> 
> 
> "KIRKLAND,BRIA
> NTo: "'[EMAIL PROTECTED]'"
> (HP-PaloAlto,e<[EMAIL PROTECTED]>
> x1)" cc:
>  [EMAIL PROTECTED]>
> 
> 10/23/2001
> 05:12 PM
> Please respond
> to "LOG4J
> Users Mailing
> List"
> 
> 
> 
> Hi,
> 
> Does anyone know of an open source (or free) logging utility that is not
> limited by using static data. In the web services paradigm, multiple web
> services will be running on the same machine, and will need the ability to
> log to separate places with completely un-related configurations.
> 
> Thanks,
> 
> ~Brian Kirkland
> Advanced Technologies Group
> Hewlett-Packard
> (650) 314-4069
> ecardFile: Brian Kirkland
> 
> A Life? Cool! Where can I download one of those from?
> 
> -
> 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: Design: How to do the following with Log4j

[Anders Kristensen]

[EMAIL PROTECTED] wrote:
> 
> Anders,
> 
>  The SocketAppender automatically serializes the LoggingEvent by
> writing the object to the ObjectOutputStream and therefore because the
> message field in the LoggingEvent is marked "transient" the message object
> is not sent across the wire.

I realize that. What I meant is that you could write an appender that
serializes the logged Object in addition to the LoggingEvent. I agree it
doesn't happen just be serializing the LoggingEvent so the appender
would have to do it itself.

Anders


> 
> Maybe I am going about this  the wrong way? Does anyone have these type of
> requirements in their system? How are you solving them?
> 
> I was thinking that I could get away without having to extend ANY classes
> except LoggingEvent on the client side logging and I could do something
> like:
> 
>  // Create a category to log quote requests
>  Category cat = Category.getInstance("quote.request");
> 
>  // QuoteRequestEvent would extend LoggingEvent
>  QuoteRequestEvent evt = new QuoteRequest(username, symbol, "Quote
> Requested", source_ip);
> 
>  // Use the existing mechanism to send log request over the
> SocketAppender to the remote logger
>  cat.info(evt);
> 
> Then on the remote logger in the JDBC appender I would check the instance
> of the LoggingEvent and if it was my special one, I could get the fields I
> need and log them. If it was a generic LoggingEvent then I'd just log the
> message. The same would be true for any other appender.
> 
> Thanks,
>   - Tim
> 
> 
> Timothy G. Mullé
> Senior Software Architect
> Reuters Valley Forge Solutions Center
> 1000 Madison Avenue
> Norristown, PA 19403-2432
> 
> Phone: (610) 650-8600 x8340
> Fax:  (610) 650-8170
> 
> 
> Anders Kristensen
> <[EMAIL PROTECTED]>
> csoft.com> cc:
>Subject: Re: Design: How to do 
>the following with Log4j
> 07/30/2001 10:34 AM
> Please respond to
> "LOG4J Users
> Mailing List"
> 
> 
> 
> How about writing a custom appender (or derive from SocketAppender - it
> would be almost identical) that serializes the logged Object rather than
> rendering it?
> 
> Anders
> 
> Timothy Mulle' wrote:
> >
> > True, however since we will be primarily logging to a remote log4j server
> > and we need to send about 15 fields of data and save each field in a
> > database table, it would be ideal to send a HashMap or something filled
> with
> > these fields. Other wise it gets ugly having to create a method in an
> > extended Category class like Cat.info(field1, field2, field3, field4,
> > field5, etc..) to log all 15 fields everytime they need to log. I've
> already
> > thought about the ObjectRenderers, but because we are logging remotely,
> i'd
> > lose the structure of the object due to the actual message object stored
> in
> > the LoggingEvent not being serialized.
> >
> > I guess the only way I can see doing what I want is to do it the ugly way
> > and extend the Category class, create a new event object, and place all
> the
> > fields in that event object one by one.
> >
> > For example I wanted to do the following:
> >
> > // Client side
> > Map headers = new HashMap();
> > headers.put("servername", name);
> > headers.put("date", date);
> > headers.put("referrer", ref);
> > headers.put("message", "Page Hit Occurred");
> > etc...
> >
> > Category cat = Category.getInstance("pagehit");
> > cat.info(headers); <== Sends the object over the wire as a
> seriablized map
> >
> > // Server Side (remote)
> > Would receive the logging Event from the wire, deserialize it,
> and pull the
> > fields out and use the JDBCAppender to put the fields
> > into the database one by one.
> >
> > - Tim
> >
> > -Original Message-
> > From: Sam Newman [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, July 26, 2001 4:15 AM
> > To: LOG4J Users Mailing List
> > Subject: Re: Design: How to do the following with Log4j
> >
> > Surely though you are only sending the string representation if you
> actually
> > make your message a string? You can send

Re: Design: How to do the following with Log4j

[Anders Kristensen]

How about writing a custom appender (or derive from SocketAppender - it
would be almost identical) that serializes the logged Object rather than
rendering it?

Anders


Timothy Mulle' wrote:
> 
> True, however since we will be primarily logging to a remote log4j server
> and we need to send about 15 fields of data and save each field in a
> database table, it would be ideal to send a HashMap or something filled with
> these fields. Other wise it gets ugly having to create a method in an
> extended Category class like Cat.info(field1, field2, field3, field4,
> field5, etc..) to log all 15 fields everytime they need to log. I've already
> thought about the ObjectRenderers, but because we are logging remotely, i'd
> lose the structure of the object due to the actual message object stored in
> the LoggingEvent not being serialized.
> 
> I guess the only way I can see doing what I want is to do it the ugly way
> and extend the Category class, create a new event object, and place all the
> fields in that event object one by one.
> 
> For example I wanted to do the following:
> 
> // Client side
> Map headers = new HashMap();
> headers.put("servername", name);
> headers.put("date", date);
> headers.put("referrer", ref);
> headers.put("message", "Page Hit Occurred");
> etc...
> 
> Category cat = Category.getInstance("pagehit");
> cat.info(headers); <== Sends the object over the wire as a seriablized map
> 
> // Server Side (remote)
> Would receive the logging Event from the wire, deserialize it, and pull the
> fields out and use the JDBCAppender to put the fields
> into the database one by one.
> 
> - Tim
> 
> -Original Message-
> From: Sam Newman [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 26, 2001 4:15 AM
> To: LOG4J Users Mailing List
> Subject: Re: Design: How to do the following with Log4j
> 
> Surely though you are only sending the string representation if you actually
> make your message a string? You can send any object you like as the message,
> e.g. cat.warn(new Integer()) or whatever. You then use the ObjectRenderers
> to convert this to a string representation. I could easily see you sending
> your own object and writing a renderer to convert this to a string
> 
> sam
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Wednesday, July 25, 2001 9:22 PM
> Subject: RE: Design: How to do the following with Log4j
> 
> >
> > Yes I have looked into those..however, it appears that when I want to log
> > to a remote server, I will be sending the string representation down the
> > wire, which I'd have to then parse into an object on the log server so I
> > can access the individual fields. It would be much more useful to send the
> > object down the wire so we can then work on the message object whether it
> > was local or remote.
> >
> > - Tim
> >
> 
> -
> 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]

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

Re: How to switch off the loging?

[Anders Kristensen]

That sounds pretty dubious to me. I don't think it will work. Setting
the priority to something high does work fine and I think if we wanted
to allow disabling logging for a category without risking something
being logged anyway, the way to do it would be to have a special
priority higher than FATAL with which categories can be configured but
log messages can't be generated. Since in practice this doesn't seem to
be a real problem I wouldn't worry about it, though.

Anders


Thilo Schottelius wrote:
> 
> Dear Anders,
> how do you think about the idea to remove a created instance of a category
> from the Hashtable of class Hierarchy? This would disable all the logging to
> this instance/class.
> 
> Thilo
> 
> -Original Message-
> From: Anders Kristensen [mailto:[EMAIL PROTECTED]]
> Sent: Mittwoch, 27. Juni 2001 22:56
> To: LOG4J Users Mailing List
> Subject: Re: How to switch off the loging?
> 
> Just set the priority associated with the category to something really
> high, e.g. FATAL. This effectively turns off logging for that category.
> (Yes, something logged with priority FATAL will still get logged -- you
> could argue for and against this behaviour but that's how it currently
> works.)
> 
> Anders
> 
> [EMAIL PROTECTED] wrote:
> >
> > But I only want to switch off the logging of a specific category. The
> disableall
> > will disable the logging of all catogories?
> >
> > Thanks,
> > Peter
> >
> > Reply Separator
> > Subject:RE: How to switch off the loging?
> > Author: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
> > Date:   6/27/01 12:06 PM
> >
> > Sorry, BasicConfigurator.disable seems to be deprecated. You can use
> > Category.getDefaultHierarchy().disableAll()
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 27, 2001 11:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: How to switch off the loging?
> >
> > I have a category com.mycompany.prod. How to switch off it's loging? I
> mean
> > do
> > not let it log any message to it's appender.
> >
> > Thanks,
> > Peter
> >
> > -
> > 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]
> >
> > Received: from omnivor1.rsp.comsat.com ([134.133.178.45]) by
> > cqgate5.cmc.comsat.com with SMTP
> >   (IMA Internet Exchange 3.13) id 0038C287; Wed, 27 Jun 2001 15:31:38
> -0400
> > Received: from omnivor1.rsp.comsat.com ([134.133.178.45]) by
> > omnivor1.rsp.comsat.com with SMTP (Microsoft Exchange Internet Mail
> Service
> > Version 5.5.2650.21)
> > id MQS4ACVL; Wed, 27 Jun 2001 15:27:01 -0400
> > Received: FROM neo.it.comsat.com BY omnivor1.rsp.comsat.com ; Wed Jun 27
> > 15:27:01 2001 -0400
> > Received: from apache.org (h31.sny.collab.net [64.208.42.41])
> > by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id
> f5RJDFj22921
> > for <[EMAIL PROTECTED]>; Wed, 27 Jun 2001 15:13:15 -0400 (EDT)
> > Received: (qmail 8257 invoked by uid 500); 27 Jun 2001 19:20:20 -
> > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > Precedence: bulk
> > List-Post: <mailto:[EMAIL PROTECTED]>
> > List-Help: <mailto:[EMAIL PROTECTED]>
> > List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> > List-Subscribe: <mailto:[EMAIL PROTECTED]>
> > Reply-To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
> > Delivered-To: mailing list [EMAIL PROTECTED]
> > Received: (qmail 8067 invoked from network); 27 Jun 2001 19:20:15 -
> > Message-ID: <[EMAIL PROTECTED]>
> > From: Veerappan Saravanan <[EMAIL PROTECTED]>
> > To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]>
> > Subject: RE: How to switch off the loging?
> > Date: Wed, 27 Jun 2001 12:06:36 -0700
> > MIME-Version: 1.0
> > X-Mailer: Internet Mail Service (5.5.2653.19)
> > Content-Type: text/plain;
> > X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
> >
> > -
> > 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]
> 
> -
> 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: How to switch off the loging?

[Anders Kristensen]

Just set the priority associated with the category to something really
high, e.g. FATAL. This effectively turns off logging for that category.
(Yes, something logged with priority FATAL will still get logged -- you
could argue for and against this behaviour but that's how it currently
works.)

Anders


[EMAIL PROTECTED] wrote:
> 
> But I only want to switch off the logging of a specific category. The disableall
> will disable the logging of all catogories?
> 
> Thanks,
> Peter
> 
> Reply Separator
> Subject:RE: How to switch off the loging?
> Author: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
> Date:   6/27/01 12:06 PM
> 
> Sorry, BasicConfigurator.disable seems to be deprecated. You can use
> Category.getDefaultHierarchy().disableAll()
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 27, 2001 11:58 AM
> To: [EMAIL PROTECTED]
> Subject: How to switch off the loging?
> 
> I have a category com.mycompany.prod. How to switch off it's loging? I mean
> do
> not let it log any message to it's appender.
> 
> Thanks,
> Peter
> 
> -
> 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]
> 
> Received: from omnivor1.rsp.comsat.com ([134.133.178.45]) by
> cqgate5.cmc.comsat.com with SMTP
>   (IMA Internet Exchange 3.13) id 0038C287; Wed, 27 Jun 2001 15:31:38 -0400
> Received: from omnivor1.rsp.comsat.com ([134.133.178.45]) by
> omnivor1.rsp.comsat.com with SMTP (Microsoft Exchange Internet Mail Service
> Version 5.5.2650.21)
> id MQS4ACVL; Wed, 27 Jun 2001 15:27:01 -0400
> Received: FROM neo.it.comsat.com BY omnivor1.rsp.comsat.com ; Wed Jun 27
> 15:27:01 2001 -0400
> Received: from apache.org (h31.sny.collab.net [64.208.42.41])
> by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f5RJDFj22921
> for <[EMAIL PROTECTED]>; Wed, 27 Jun 2001 15:13:15 -0400 (EDT)
> Received: (qmail 8257 invoked by uid 500); 27 Jun 2001 19:20:20 -
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Precedence: bulk
> List-Post: 
> List-Help: 
> List-Unsubscribe: 
> List-Subscribe: 
> Reply-To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> Received: (qmail 8067 invoked from network); 27 Jun 2001 19:20:15 -
> Message-ID: <[EMAIL PROTECTED]>
> From: Veerappan Saravanan <[EMAIL PROTECTED]>
> To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]>
> Subject: RE: How to switch off the loging?
> Date: Wed, 27 Jun 2001 12:06:36 -0700
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Content-Type: text/plain;
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
> 
> -
> 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: FW: Log4J questions

[Anders Kristensen]

See the log4j javadoc documentation for the PatternLayout %M and %C
conversion characters. They're implemented in the same manner as in the
JSR 47 framework -- both extract info from a call stack obtained from a
rendered exception. This is not reliable -- stack trace layout is not
standardized and JVM's are free to perform various optimizations, e.g.
inlining, which remove stack frames completely.

I don't think we want a Category constructor which depends on something
which is inherently unreliable, so you can probably forget about such a
no-arg constructor. BTW, this can't be a constructor anyway because
log4j has to guarantee that an existing Category is returned if one
existed with that name. It can do that in a static getInstance method
but not in a ctor.

Anders


"Adam L. Menkes" wrote:
> 
> Though Sun's JDK 1.4 logging is bad compared to what Log4J appears
> capable of doing, there are some things that I saw that I liked, but
> could not figure out how to do in Log4J.
> 
> Specifically, the logging of class/method names without having to
> provide them. For example, in JDK 1.4 beta, you can do the following:
> 
> logger.config("Some message");
> 
> And it will provide the following info (I added the color for
> emphasis):
> 
> Jun 26, 2001 12:52:11 PM LogTest 
> INFO: Some message
> 
> As you can see, it picks up the class name and method (in this case,
> the constructor, represented by "").
> 
> Note that .config is only used for example, as normally you would use
> logger.entering() / logger.exiting() (see bug ID #4474150).
> 
> This is very useful, since class names may change (though infrequent)
> and method names change (more frequent), plus, it allows for
> copy/paste of standard calls to every method:
> 
> logger.entering();
> 
> ...
> 
> logger.exiting();
> 
> Also, if a class inherits from another class, it would be nice if it
> reported the actual class ("entering Apple" instead of the superclass
> "entering Fruit") without having to account for the differences.
> 
> Similarly, it would be nice if Category.getInstance() could add a
> no-arg constructor which would determine the class without having to
> add "MyClass.class" or "MyClass.class.getName()". I would make it
> additional, and not deprecate the existing, as you may want to setup
> global (public static) Category in a separate class.
> 
> -
> 
> On another note, just FYI, there are some typos in your documentation.
> In examples (and examples/doc-files), the *.lcf files spell
> "documentation" incorrectly (documenation).
> 
>

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

Re: How early

[Anders Kristensen]

After.

Anders

Thomas Tuft Muller wrote:
> 
> Hi,
> 
> Before I start digging into the code, maybe someone here knows the answer to
> this:
> 
> If I add an ObjectRenderer to the default Hierarchy, is the string
> determined _before_ or _after_ the decision whether to log at all (due the
> log-level or if logging is turned off) is made?
> 
> The thing is, I do some quite heavy reflection in a lot of the renderers,
> and I rather see that these are not conducted if logging is filtered away
> anyway.
> 
> --
> 
> Thomas
> 
> *
> Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved.
> Confidential. No liability whatsoever is accepted for any loss or damage
> suffered as a result of accessing this message or any attachments.
> 
> -
> 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: Option data of user-defined conversion specifier

[Anders Kristensen]

Agreed. I've made those methods protected in the CVS archive.

Anders

Ernie Parker wrote:
> 
> Hello Log4j,
> 
> I'm adding my own conversion specifier %v{option} using subclassed
> PatternLayout, PatternParser and PatternConverter.  I have a small
> problem with the {option} part. There doesn't seem to be a method for me
> to extract it. In the finalizeConverter method of my PatternParser subclass,
> I would like to be able to call
> 
>addConverter(new MyPatternConverter(formattingInfo, extractOption()));
> 
> The problem is that extractOption() is a private method of PatternParser.
>  I can't access it from my subclass.
> 
> The org.apache.log4j.helpers.PatternParser has private methods,
> extractOption()and extractPrecisionOption(), which, I believe, should be
> protected so that a subclass, also, can access the option for conversion
> specifiers.  Interestingly enough, these methods access protected
> data members.  As a result I can copy the entire method in my subclass
> and everything works fine. But I'm sure that is not an approved way
> to modify the format buffer.
> 
> Maybe I've missed something in the architecture. If so, please let me know.
> 
> Regards,
> Ernest Parker
> 
> -
> 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: while we are talking about NDC

[Anders Kristensen]

This is essentially the same idea that Ceki floated previsouly under the
name "Mapped Diagnostic Context" -- a per-Thread String-to-String map:

  http://marc.theaimsgroup.com/?l=log4j-dev&m=98051571516266&w=2

It's a good idea but hasn't been implemented yet (to my knowledge).

Cheers,
Anders


Seemantini Godbole wrote:
> 
> Hi all,
> 
> For last couple of weeks I have been using log4j and is working very well
> for our logging needs. Ours is a typical J2EE architecture, with JSP,
> servlets,  EJB combination.
> 
> However, we need some client specific info such as the name of the user who
> logged in, client ip address, request type (login, booking etc)..
> 
> I have been pushing all this info into NDC, which works well also. Now we
> have need to print some and not all info in NDC. Currently with usage of %x,
> we get it all or none at all.
> 
> I was thinking of writing a NameValueNDC class which will look mostly like
> NDC. Instead of associating a Stack in the static hashtable, it would
> associate another hashtable with every thread in the main hashtable.
> 
> In essence, instead of
> 
> NDC--->Hastable- Thread1--->Stack1
>|---Thread2--->Stack2
> 
> we will have
> 
> NDC--->Hastable- Thread1--->Hashtable1
>|---Thread2--->Hashtable2
> 
> and then, we could have some more characters in Pattern* classes, such as %o
> for loginName. At the time of printing to the log, %o will prompt the
> Pattern* classes to get LoggingEvent.getNDC.get("loginName"), instead of
> whole NDC and print it to the log. This means somebody will have to do
> NameValueNDC.push("loginName", "log4jUser") prior to actual logging.
> 
> pl. let me know if this is a dumb idea and if there are easier ways of
> achieving this.
> 
> Thanks,
> Seemantini
> 
> -
> 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: Digitally signing log entries

[Anders Kristensen]

So at the moment we have a bunch of "official" conversion characters in
PatternLayout. Anything not in PatternLayout is really app specific and
individual custom appenders can assign whatever meaning they like to
those characters.

IMHO, if we extend PatternLayout to support a bigger space of variables
it should be to support vairable names of any length. There is really no
reason why they have to be restricted to one or two characters. A syntax
like %{foo} would work. With format modifiers and arguments this would
be something like %-20{date}{ISO8601}. This wouldn't mean anything in
the old syntax so this is backward compatible.

Anders


Paul Glezen wrote:
> 
> yogi wrote:
> >
> > For this I'm writing a PatternConverter for a character...say 's'. This
> > converter uses javax.crypto.Mac
> 
> Hi Yogi,
> 
> You might want to check out the example in
> 
>   org.apache.log4j.examples.appserver
> 
> for an example of adding attributes to a LoggingEvent and what other
> supporting classes should be added.  There is also deepExtensions.html
> in the docs directory that gives more explanation.
> 
> You may notice that 's' is already used there (for Server name).  This
> brings up a concern I see on the horizon: not enough letters for
> meaningful conversion characters.  A possible solution is to have each
> extension have only one conversion character with sub-character in
> brackets.  For example, instead of AppServerPatternConverter using up
> four characters, ('s', 'h', 'b', 'v'), it could use just 'a' (for
> appserver) and include the other ones in brackets: "a{s}", "a{h}",
> "a{c}" and "a{v}".  (Notice I used "a{c} instead of "a{b}".  That's
> because c, which stands for "Component", was already taken by "category"
> and "Class".)
> 
> Just a thought.  I know I'm going to be tripping all over myself with
> new conversion characters that I have on deck unless I do something like
> this.
> 
> - Paul
> --
> Beware of bugs in the above code.  I have
> only proved it correct, not tried it.
> -Don Knuth
> 
> -
> 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: can Log4j configuration file be bundled with applications property file

[Anders Kristensen]

Works for me! With the following test program:

package test.log4j;

import org.apache.log4j.*;

public class HelloWorld {
public static void main(String[] args) throws Exception {
Category cat = Category.getInstance(HelloWorld.class);
cat.debug("hi there");
cat.info("how's it going?");
}
}

I get:

2001-06-01 16:36:21,622 DEBUG test.log4j.HelloWorld
- hi there
2001-06-01 16:36:21,652 INFO  test.log4j.HelloWorld
- how's it going?

which looks about right.

Anders


korosh wrote:
> 
> below is the contents of the property file. some values/varibles changed to
> protect the innocent.
> 
> ---
> # property file.   log4j enteries are at the end of this file.
> 
> #
> # some other logging function not related to log4j
> logging.filename=MyServer
> logging.dir=/export/home/myserver/myservletengine/servlet/ServletLogs
> 
> 
> ##
> # Properties used by another server
> 
> ##
> 
> #by the Server ( in minutes ).
> message.delay_minutes=15
> message.time_format=HH':'mm
> message.date_format=MM'/'dd
> message.use_date_for_old_message=true
> 
> #The channel on which the we broadcast
> #BCAST=BCHANNEL
> 
> 
> ##
> # Properties used by the 
> 
> ##
> 
> #Connection information for Informix
> profiles.jdbc_url=jdbc:informix-sqli://me.myserver.com:1525/e:INFORMIXSE
> RVER=xxx
> profiles.jdbc_username=x
> profiles.jdbc_password=x
> profiles.jdbc_class=com.informix.jdbc.IfxDriver
> 
> 
> ###
> # Properties used by Sea
> 
> ###
> 
> #The search database table name
> #search.jdbc_table=ps_search_master
> 
> #The class of the database driver
> #search.jdbc_class=com.informix.jdbc.IfxDriver
> 
> #minutes between reads of updates to seach master table
> #search.refresh_minutes=15
> 
> search.refresh_minutes=15
> 
> 
> ###
> # Properties used by x
> 
> ###
> news.proxied_server_name = http://news.someserver.com/news
> news.symbol_to_url_rule = sds_hl.asp?symbol=%s&clients=7899
> news.default_url = sds_hl.asp?symbol=&clients=7899
> news.error_text.0 = ODBC Drivers error
> news.error_text.1 = Server object error
> news.error_text.2 = Server.CreateObject
> 
> 
> ###
> # Properties used by statistics server
> 
> ###
> log4j.rootCategory=, A1
> # log4j.appender.A1=org.apache.log4j.ConsoleAppender
> log4j.appender.A1=org.apache.log4j.FileAppender
> log4j.appender.A1.File=MyLog.log
> log4j.appender.A1.layout=org.apache.log4j.PatternLayout
> log4j.appender.A1.layout.ConversionPattern=%d{ISO8601} %-5p %37c %3x - %m%n
> log4j.category.com.mycomp.HandlerServlet=INFO
> log4j.category.com.mycomp.Handler1=INFO
> log4j.category.com.mycomp.Handler2.DB=WARN
> log4j.category.com.mycomp.DatabaseConnectionPool.DB=INFO
> log4j.category.com.mycomp.HandlerFactory=INFO
> jdbcClassName=com.informix.jdbc.IfxDriver
> poolsize=5
> databaseURL=jdbc:informix-sqli://myserver:1532/mydb:INFORMIXSERVER=myserver
> username=x
> password=x
> 
> -
> -Original Message-
> From: Anders Kristensen [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 31, 2001 9:45 PM
> To: LOG4J Users Mailing List
> Subject: Re: can Log4j configuration file be bundled with applications
> property file
> 
> I think what you're describing ought to work just fine. Can you send a
> properties file that contains non-log4j entries and which fails
> configuring correctly?
> 
> Anders
> 
> korosh wrote:
> >
> > Hi,
> >
> > I have a web application that uses Log4j.
> >
> > I have alot of properties associated with this web application that I read
> > off of a main property file.
> >
> > Wonderining if I could take all of the log4j varible=value pairs and just
> > put them into this property file, c

Re: can Log4j configuration file be bundled with applications property file

[Anders Kristensen]

I think what you're describing ought to work just fine. Can you send a
properties file that contains non-log4j entries and which fails
configuring correctly?

Anders


korosh wrote:
> 
> Hi,
> 
> I have a web application that uses Log4j.
> 
> I have alot of properties associated with this web application that I read
> off of a main property file.
> 
> Wonderining if I could take all of the log4j varible=value pairs and just
> put them into this property file, call it myprops.properties and then feed
> this to the log4j configurator like:
> 
> PropertyConfigurator.configure( myprops.properties )
> 
> ???
> 
> I tried the above, but the log4j complained that no appender defined for A1
> (my appender).
> 
> I took the log4j varible/value pairs out of myprops.properties and put them
> into a seperate file and that did the job.
> 
> all the entires in myprops.properties are varible/value pairs anyways. I
> assumed PropertyConfigurator would simply throw away all the other
> properties and only load the log4j.* entries.
> 
> any ideas?
> 
> i'd rather have one property file for my application only.
> 
> -
> 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: Help on property file settings for Appenders and Layouts

[Anders Kristensen]

Maybe it would be useful for us to have a convention of listing all
configurable properties of components in the "class-level" javadoc
comment. For each property there'd be the name and a link to the
associated setter method. I s'pose not all setters are necessarily
intended for configuration.

Anders


Ceki Gülcü wrote:
> 
> At 13:27 24.05.2001 +0100, you wrote:
> >Hi all,
> >I'm just trialing Log4J as a new logging solution for our system and I'm
> >trying to configure the appenders and layouts by property file. Is there any
> >documentation of the possible property settings for each of the Log4J
> >classes (e.g DailyRollingFileAppender and HTMLLayout). Looking through the
> >exxamples they show a few of the settings but not all of them, where would I
> >find the rest?
> >
> >regards,
> >Mike Hurd
> 
> This is a new FAQ entry:
> 
> What are the configurable options for FooBarAppender?
> 
> Log4j uses JavaBeans style configuration.
> 
> Thus, any setter method in FooBarAppender corresponds to a configurable option. For 
>example, in RollingFileAppender the setMaxBackupIndex(int maxBackups) method 
>corresponds to the maxBackupIndex option. The first letter of the option can be upper 
>case, i.e. MaxBackupIndex and maxBackupIndex are equivalent but not MAXBACKUPIndex 
>nor mAXBackupIndex.
> 
> Layouts options are also defined by their setter methods. Same goes for most other 
>log4j components.
> 
> Hope this answers the question. Ceki
> 
> -
> 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: Hierarchy references

[Anders Kristensen]

Thomas Tuft Muller wrote:
> 
> Anders Kristensen wrote:
> | Thomas Tuft Muller wrote:
> | > I probably miss a few things, but it seems like the LoggingEvent doesn't
> | > contain the original Object (only the message i.e. the string version
> | > (toString() of it) passed from the application. The
> | LoggingEvent is passed
> | > to each member of the list of PatternConverters from
> | PatternLayout and ends
> | > up being passed to the overrided convert(LoggingEvent) method.
> | How do I get
> | > hold of the original object from this point?
> |
> | The original Object is in the LoggingEvent. You get it by calling
> | getMessage().
> 
> Not it version 1.0.4 ;) I've downloaded the latest now.
> 
> | > I certainly like the idea of having rules (patterns) for conversion of
> | > different types, but I guess the PatternLayout class is no good
> | for this(?)
> | >
> | > Any suggestions for a flexible design and some hints how to
> | implement it?
> 
> [snip]
> | 3. In the ObjectRenderer. This is similar to 2, but instead of asking
> | the LoggingEvent to resolve an unkown conversion character to a String,
> | the PatternLayout asks the ObjectRenderer associated with the logged
> | Object:
> |
> |   void format(Object msg, char conversionChar, StringBuffer sbuf);
> 
> Do you sugges the the ObjectRenderer implements this method? If this is the
> case, some checking and casting must be done somewhere.

The method would be added to the ObjectRenderer interface. No checking
or casting is needed anywhere.

Maybe I wasn't being clear about it, but the proposal is to add support
for what you ask for in log4j itself. If you wanted to use this scheme
yourself on top of 1.1.1 or earlier versions of log4j, you would indeed
have to cast the ObjectRenderer in your PatternLayout.

> 
> | The first argument might be the whole LoggingEvent instead of just the
> | logged Object.
> |
> | Option 3 seems by far the best and most flexible to me, e.g.
> |
> |   - can accommodate per-Class custom conversion characters
> 
> Yes.
> 
> |   - can accommodate different per-category rendering
> 
> How? Renderers are still global or what? Do you suggest that the renderer
> gets information about the category calling it in order to differentiate?

Renderers are global but Layouts are not. Rendering would use
PatternLayout with conversion strings containing custom conversion
characters. These are resolved by the ObjectRenderer, but different
Categories may have different conversion strings.

One objection to what I'm proposing would be that it elevates one
particular Layout to a special status. The log4j "core" includes the
notion of ObjectRenderers and Layouts, but is completely agnostic of how
particular Layouts do their job. This proposal would give special status
to PatternLayout in that the ObjectRenderer interface would have a
method specially designed to work with it.

I think in reality, however, there is only really one Layout. The other
ones which are part of log4j can be seen as shorthands for
PatternLayout, and the layouts users write themselves are mostly
concerned, I believe, with logging custom objects, and so would likely
benefit from this extension.

> 
> |   - no need to subclass PatternLayout as in 1.
> 
> How can I call the "custom" method on the renderer if I don't subclass
> PatternLayout?

It would be done by PatternLayout itself in a future modified version.
If you want to implement this scheme now, you do need to write a simple
extension to PatternLayout which handles costum conversion characters by
obtaining the objectrenderer for the logged Object, casts it, and
invokes the format method. It's a lot less attractive if not part of
log4j itself.

--
Anders Kristensen

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

Re: [HELP] Urgent help on log4j Appenders being nullified

[Anders Kristensen]

Sounds weird. Have you tried running with the log4j.configDebug variable
defined (java -Dlog4j.configDebug ...)? It might give some idea.
Otherwise it would be useful if you could reproduce the problem in a
small test program or something and send it to the list.

Cheers,
Anders


John Waugh wrote:
> 
> As I've said in my previous mails (to little avail) I keep getting
> complaints from log4j about the fact that there are no appenders on my
> categories, so I wrote a couple of functions that will take a category
> and search the hierarchy for appenders, if they find one, they will
> add it to this category, so it has an appender (so I should get no
> complaints!!). did that, still got complaints.
> 
> so I opened up log4j and looked at the src.
> in the cateogry.callAppenders fn, the point where the complaint was
> comping from  it turns out writes was 0, meaning it had checked the
> hierarchy for parent etc... category appenders (as near as makes no
> difference for the sake of this arg), found none, so hadn't written
> the log to any log files.
> 
> now the interesting part.
> It seems every time i run my program the complaint comes from logging
> in one of two threads. not necessarily the same one each time i run
> the program.
> 
> so, i write out the memory addresses of the category being made, the
> appenders added to it, and the categories and appenders being checked
> when it calls callAppenders.  It turns out that although when created
> the categories in both threads have valid references, and appenders
> with valid references added to them, after the complinat (which
> happens early on in the program life) one of the threads categrories
> has the same references (hardly expected to change) but now the
> appenders are all null.
> 
> I never set them to null, so any idea why this happens?

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

Re: Hierarchy references

[Anders Kristensen]

Thomas Tuft Muller wrote:
> 
> | > I think this is an important requirement; for Category X I
> | would like to log
> | > java.lang.Integer as "Integer: " + Integer.toString( theInt ), and in
> | > category Y I would like to log it as Integer.toString( theInt ).
> | >
> | > Is it possible?
> |
> | Nope. You can't do that. An ObjectRenderer renders the same for all
> | categories.
> 
> Is this a design flaw?

It's just how ObjectRenderers currently work.

> 
> | If you need per-category rendering yo may have to write a Layout which
> | knows about the types of Object you log (Integers in your example), e.g.
> | a subclass of PatternLayout which recognixes custom conversion
> | characters related to your logged Objects.
> 
> Sounds like a good idea.
> 
> | Actually, in your example you can just use PatternLayout without any
> | extension. Basically the %m ends up being populated by calling toString
> | on your object (unless you explicitly register an ObjectRenderer for
> | Integers), so you could have a pattern "Integer: %m%n" on Category X and
> | "%m%n" on Category Y and the effect should be as you described.
> 
> This imposes a category per type(?), which is not what I want. I want each
> category to have a particular formatting of an arbitrary number of types
> irrespective of what toString() for the objects returns. E.g. for
> java.net.InetAddress could possible strings be the hostname, the raw
> IP-address, or both, preferrable formatted in a flexible way. In other
> words, the stringification of an object passed to the category should be
> formatted according to other method calls on the object than toString().

I see. That sounds reasonable and like something generally useful.

 The
> ObjectRenderer interface hides an implementation of how this is done for
> each type, but as I found out (and you confirmed) log4j stores renderers
> globally rather than on a per Category basis.

Right.

> 
> I probably miss a few things, but it seems like the LoggingEvent doesn't
> contain the original Object (only the message i.e. the string version
> (toString() of it) passed from the application. The LoggingEvent is passed
> to each member of the list of PatternConverters from PatternLayout and ends
> up being passed to the overrided convert(LoggingEvent) method. How do I get
> hold of the original object from this point?

The original Object is in the LoggingEvent. You get it by calling
getMessage().

> 
> I certainly like the idea of having rules (patterns) for conversion of
> different types, but I guess the PatternLayout class is no good for this(?)
> 
> Any suggestions for a flexible design and some hints how to implement it?

Well, we're talking about something like adding conversion characters to
a PatternLayout in a way that's type specific (type here means on basis
of Class of logged Object).  Three ways this might work depending on
where the knowledge of what new conversion characters mean lives:

  1. In PatternLayout subclasses. This is the case I was describing
before. As you point out it's limited in that knowledge of different
types of logged Objects is hardcoded in the Layout, and you might even
have to do ugly switching on Class of logged Object.

  2. In the LoggingEvent itself. In such a scheme apps might subclass
Category and LoggingEvent for different types of logged object and as
part of that they'd implement a LoggingEvent method

  void format(char conversionChar, StringBuffer sbuf);

When a PatternLayout see a conversion character it doesn't know about,
it invoked this format method on the LoggingEvent itself.

  3. In the ObjectRenderer. This is similar to 2, but instead of asking
the LoggingEvent to resolve an unkown conversion character to a String,
the PatternLayout asks the ObjectRenderer associated with the logged
Object:

  void format(Object msg, char conversionChar, StringBuffer sbuf);

The first argument might be the whole LoggingEvent instead of just the
logged Object.

Option 3 seems by far the best and most flexible to me, e.g.

  - can accommodate per-Class custom conversion characters
  - can accommodate different per-category rendering
  - no need to subclass PatternLayout as in 1.
  - no need to subclass Category and LoggingEvent as in 2.

I'm +1 on this scheme.

--
Anders Kristensen

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

Re: Hierarchy references

[Anders Kristensen]

Thomas Tuft Muller wrote:
> 
> | Can you please expand? What type of object renderers
> | have you implemented?
> 
> I develop telephony applications based on JTAPI. I have implemented
> different renderers for the core interfaces, like javax.telephony.Call,
> javax.telephony.Connection etc. In this way I can get varying depth of
> information about the different objects implementing the interfaces. As for
> now I have a simple, medium, and extensive renderer for each interface.
> 
> The problem is that I can only register a renderer for a certain class in
> the default hierarchy whereby the renderer becomes 'global'. I would like to
> register a SimpleCallRenderer in category x and an ExtensiveCallRenderer in
> Category y.
> 
> | Why do you need different renderers on a category
> | basis? Can you please explain?
> 
> I think this is an important requirement; for Category X I would like to log
> java.lang.Integer as "Integer: " + Integer.toString( theInt ), and in
> category Y I would like to log it as Integer.toString( theInt ).
> 
> Is it possible?

Nope. You can't do that. An ObjectRenderer renders the same for all
categories.

> 
> I've just a limited understanding of the detail design of Log4j, but I would
> think the granularity of renderers should be the same as for Layouts, that
> is, on a Category basis.

If you need per-category rendering yo may have to write a Layout which
knows about the types of Object you log (Integers in your example), e.g.
a subclass of PatternLayout which recognixes custom conversion
characters related to your logged Objects.

Actually, in your example you can just use PatternLayout without any
extension. Basically the %m ends up being populated by calling toString
on your object (unless you explicitly register an ObjectRenderer for
Integers), so you could have a pattern "Integer: %m%n" on Category X and
"%m%n" on Category Y and the effect should be as you described.

--
Anders Kristensen

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

Re: Asking again: Adding log-time conversion characters

[Anders Kristensen]

David Thielen wrote:
> 
> I looked at that - org.apache.log4j.examples.appserver adds it's data at
> Category constructor time. I need to add items at the time the log line item
> is written. I need to log the user - we attach a user token to each session
> and I can get that from the thread. But when an object is created  - it can
> be used by multiple users so I can't set it at construction time.

This is from memory, so bear with me.

You can do what you want by extending Category and LoggingEvent and
adding method(s) to your subclass of Category which takes additional
arguments (whatever custom data you need to log). Those new methods
creates instances of your subclass of LoggingEvent. This subclass has
attributes for holding your additional data. Then you write a subclass
of PatternLayout which recognizes your additional conversion characters
and pulls data out of your custom LoggingEvent accordingly.  This is the
scheme described in Pauls appserver example.

You say that your data is availeble to the thread doing the logging. If
this means it's also available to the PatternLayout subclass then
there's a simpler and better way of doing things. Basically, you just
don't extend Category and LoggingEvent, but rather, in your sublcass of
PatternLayout you just extract data for your custom conversion
characters dircely from the "context" (e.g. ThreadLocals if that's what
you're usign).  This is a good thing because using Category subclasses
can be problematic and is best avoided if possible.

Another approach which also avoids creating subclasses of Catgeory is to
define a "data class" holding your custom app data elements, and then
log instance of this class rather than Strings, e.g.

  public class AppData {
public Foo foo;
public Bar bar;
public Baz baz;

...
  }

and then in your logging code:

  category.info(new AppData(...));  

In your PatternLayout subclass you can then cast the result of
LoggingEvent.getMessage() and retrieve the attributes as appropriate.
You could define a custom ObjectRenderer but that has limitations
compared to subclassing PatternLayout. Still, if you define a toString()
on AppData, then the defaultRenderer will use that method be get a
String for %m. Maybe I make all this sound very complicated, but it
really isn't.

Cheers,
Anders

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

Re: dumping log4j configuration [WAS: syslog vs. log4j]

[Anders Kristensen]

Paul Glezen wrote:
> 
> > I think Syslog's configurations are more flexible. With Syslog, you
> > can modify a running configuration and ask it to write its
> > configuration out to an XML file to be read in later.
> 
> Cool.  I belive log4j's config mechanism is quite flexible.  One can
> also change it programmatically at runtime.  I don't believe log4j will
> write a property/xml file with the currently running configuration.  We
> might consider doing that some time if anyone wants to code it.  It
> would be a nice feature.

It's a done deal. Up to a point, anyway. Have a look at PropertyGetter
and PropertyPrinter in org.apache.log4j.config as well as
PrintProperties in the test package. The two former classes together
provide support for dumping the current log4j configuration to a
properties config file.

It cannot handle all aspects of config files, especially not some of the
more advanced features which are in the DOMConfigurator and not the
PropertyConfigurator. Also, there's currently no way of generating an
XML config file, only properties file.  I was planning on adding some of
those missing parts and then use them to write a small transcoding
utility which would translate between different config formats simply by
using one configurator to to configure log4j in teh usual manner and
then use a "config writer" for outputting the current log4j
configuration in a different format (or the same as a way to get
pretty-printing, maybe).

I was (am, when I find the time) going to use this feature as part of
way to have a console tool connect to a running JVM with log4j
configured. The console would connect, retrieve the current
configuration, set up a new hierarchy of its own with the configuration
retrieved from the other guy (possibly massaged somehow), and then have
other guy add a SocketAppender at select points in it's configuration
hierarchy. This would allow the console to receive logging data and
render it just like it's rendered by the "other guy". Sounds like fun,
no?

Cheers,
Anders

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

Re: Configuration File

[Anders Kristensen]

You can configure components such as appenders and layouts with values
from the log4j configuration files. It sounds to me like what you really
want to do is to define the contact info as attributes of your
appender(s) and/or layout(s) rather than the category itself.

It's not really clear how you want to use the contact info, but say you
want to put it into logged data, you might simply make it part of a
PatternLayout conversion pattern.  If you wanted the contact info to be
used to figure out where to send logging data to, it would be configured
as part of the appender, e.g. as "To" paramater on an SMTPAppender.

Doesn't sound to me like the Category should know about this.

Anders


[EMAIL PROTECTED] wrote:
> 
> I have extended log4j to use my own Category.  I am adding some additional
> logging methods such as notify, and would like to embed the proper email
> address and phone numbers in the properties file.  Something like
> '[EMAIL PROTECTED]'.  I want to be able to access the
> poperties file entry within my code.  Is that possible?
> 
> James Birchfield
> 
> Ironmax
> maximizing your construction equipment assets
> 5 Corporate Center
> 9960 Corporate Campus Drive,
> Suite 2000
> Louisville, KY 40223
> 
> 
> Ceki Gülcü
> <[EMAIL PROTECTED]> To: "LOG4J Users Mailing List" 
><[EMAIL PROTECTED]>
>  cc:
> 05/18/01 Subject: Re: Configuration File
> 07:35 AM
> Please
> respond to
> "LOG4J Users
> Mailing List"
> 
> 
> 
> James,
> 
> Sorry but I do not understand the question. Ceki
> 
> At 07:18 18.05.2001 -0400, you wrote:
> >I want to add some extra info in the properties file.  But for the life of
> >me, I can not figure out how to get the information out of it.  I was
> >hoping for something similar
> >to Properties props = Category.getProperties(), but can't find anything
> >like that.  Any help would be great!
> >
> >Thanks!
> >
> >James Birchfield
> 
> -
> 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]

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

Re: questions about the new bean based property framwork

[Anders Kristensen]

Jin Zhao wrote:
> 
> Hi Geeks,
> 
> I have a application based on  jakarta-log4j-1.1b, which   uses the old
> OptionHandler to deal with options/properties.
> Now in log4j-1.1b6, OptionHandler is deprecated. Since I know little about
> beans,  my question is, how can I use the current framework to do the old
> job of OptionHandler?

Basically, the JavaBeans method is to ionvoke regular Java methods for
setting properties, and not to rely on methods like getOptionStrings()
and setOption(). The entity setting the property uses reflection or the
JavaBeans introspection (which itself uses reflection) to figure out
which properties are available for a particular Java object and what the
types of those properties are (String, boolean, int, ...)

> 
> For example, I need to know options used in a object, which can be done with
> the old getOptionStrings(). How can I do that now ?

Have a look at PropertySetter, PropertyGetter in org.apache.log4j.config
and java.beans.Introspector. It's basically a matter of using the
JavaBeans Introspector.

> Also what is the replacement of setOption(key, value)?

Object-specific setter methods, for example, setFile(String name) for
FileAppender or setFacility(String factility) for SyslogAppender. There
is no longer a single generic method for setting any option on any
component.

 The reason I use
> these two APIs is because I may not know what kind of properties/options
> included in an object, but I can also set and get them conveniently.

> 
> Here is a quesiton for java bean. Can anybody tell me what design patterns
> used in beans to deal with object and properties? Flyweight?

Reflection. Knowledge of properties is inferred from the component
itself by reflection.

--
Anders Kristensen

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

Re: reloading configuration at runtime

[Anders Kristensen]

Paul Glezen wrote:
> 
> Hi Erik,
> 
> Sorry to jump in a little late.  I monitor this list on my home PC but I
> travel during the week.
> 
> Erik van Zijst wrote:
> >
> > First is the reconfiguration thing as described below in the earlier mail.
> >
> That's a tough one.  Log4j is certainly configurable at runtime.  There
> are two notions of runtime configuration.  What others call runtime
> log4j would call initialization time (via property files).  The
> configuration can also be changed later in runtime programatically.  As
> you're aware, it can only be done locally (within the same JVM).
> 
> I'm not familiar with having an EJB server call an EJB client in order
> to change client attributes (whether it be logging or otherwise).  I am
> currently working on a reasonably sized CORBA (insurance claim
> registration call center) that has recently gone in production.  To
> change client properties, we use the old-fashon approach of sending out
> modified property files to the client machine and restarting.  Most
> enterprises are very good at distributed files out to client machines in
> an automated manner.  If a particular Customer Service Rep (CSR) called
> in saying her machine was acting funny, we could either send her a
> modified property file with configuration changes or have someone at the
> CSR location (in a different timezone than some of the servers) do it
> directly.
> 
> Remote configuration is something I'm very interested in and continue to
> regularly think about.  One direction with potential is providing JMX
> implementations of certain log4j elements.  But other than Sun's
> reference implemenation and Tivoli's TMX (from IBM's alphaworks site),
> we're somewhat short of an abundance of JMX agents to choose from.

This is consistent with Java management and our recent move to a
JavaBeans based style of configuration. I'm interested in a different
type of remote configuration also which is to have a very simple
embedded HTTP server running in a JVM and be able to retrieve that VMs
log4j configuration by doing an HTTP GET and reconfiguring it by doing a
POST with the body being the Java properties or XML configuration file.
I've got such a mechanism working now and may check it in when I get
time to clean it up.

--
Anders Kristensen

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

Re: log4j and light client

[Anders Kristensen]

The log4j ant build script currently builds two jar files - one
containing everything and one which containing only the most common
components. This last one is currently about 85 Kb but there's plenty of
scope for trimming it to fit a particular environment. You'll have to go
through and see which components (appenders, layouts, filters etc.) you
need and then ditch everything else. 35 Kb may be a tough target.

Anders


[EMAIL PROTECTED] wrote:
> 
> I would like to use log4j API's in an applet viewer from a web browser.
> Is-it possible to import a light version of log4j to minimize network
> traffic?
> A jar file, which contains all classes of org.apache.log4j package, has a size of 
>35ko.
> 
> Thank you for your help,
> Alexis
> 
> **
> Ce message electronique et tous les fichiers attaches qu'il contient
> sont confidentiels et destines exclusivement a l'usage de la personne
> a laquelle ils sont adresses. Si vous avez recu ce message par erreur,
> merci de le retourner a son emetteur. Les idees et opinions presentees
> dans ce messages sont celles de son auteur, et ne representent pas
> necessairement celles du Groupe HAYS plc ou d'une quelconque de ses filiales.
> La publication, l'usage, la distribution, l'impression ou la copie non
> autorisee de ce message et des attachements qu'il contient sont strictement
> interdits.
> 
> Nous vous informons egalement que nous avons verifie l'absence de virus dans
> ce message mais que, malgre ce controle, nous ne saurions etre tenus pour
> responsables d'eventuels degats occasionnes par un virus non detecte.
> 
> This e-mail and any attached files are confidential and intended
> solely for the use of the individual to whom it is addressed. If you have
> received this email in error please send it back to the person that sent it
> to you. Any views or opinions presented are solely those of author and
> do not necessarily represent those the HAYS plc group or any of its subsidiary
> companies. Unauthorized publication, use, dissemination, forwarding, printing
> or copying of this email and its associated attachments is strictly prohibited.
> 
> We also inform you that we have checked that this message does not contain
> any virus but we decline any responsability in case of any damage caused
> by an a non detected virus.
> 
> **
> 
> -
> 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: reloading configuration at runtime

[Anders Kristensen]

Erik van Zijst wrote:
> [...]
> I'm not getting too much feedback from you guys, so I'll walk this path on my
> own (Open Source is great). If anyone's interested after all, drop me a note
> and I'll send patches.

Don't give up on us yet just because we're a bit slow. Your ideas are
interesting and by all means send them to the log4j-dev list.
Pleease ;-)

Cheers,
Anders

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

Re: interoperability

[Anders Kristensen]

The remote logging server that's part of the log4j distribution is
fairly simple and is, I believe, mostly intended for demonstration (it's
quite good, though). Clients connect to it using the SocketAppender
which sends serialized logging events over TCP. You cannot connect to
the server from a C/C++ client because you cannot (easily) create the
effect of serialized Java LoggingEvent objects.

However, you might write another TCP based appender which implements
it's own custom logging event serialization scheme. This should be quite
straightforward and the changes to the remote logging station would be
fairly small.  I haven't had time to read it yet, but maybe the reliable
syslog protocol described in

  http://www.ietf.org/internet-drafts/draft-ietf-syslog-reliable-05.txt

would make for an interesting addition to log4j.

Anders


Prasad Balasubramanian wrote:
> 
>   Hi,
> I'm new to log4cpp and want to know whether it can
> interwork with log4j remote logging server. I've an embedded box full
> of c and c++ implementations and a (log4j) logging server. Can the
> (java) server receive loggingevents and can log the events from c++
> client without much code change either at the client or server. I
> would appreciate if someone could reply ASAP.
> Thanks
> Prasad

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

Re: Tomcat and log4j (was: I am new and I am lost ...)

[Anders Kristensen]

Paul Glezen wrote:
> 
> Ceki Gülcü wrote:
> >
> 
> > Tomcat 3.x does not use log4j. However, as far as I know, Tomcat 4.0, or more 
>precisely Catalina, the Servlet container for Servlet API Specification 2.3, has 
>opted to use log4j internally. I'll double check this shortly.
> >
> > The Tomcat API provides hooks to use different logging package then the one 
>provided by tomcat internally. I have not used this extension facility extensions 
>myself. However, I intend to study it in the near future.
> >
> 
> I'm not so sure that Tomcat (or any other kind of app server) using
> log4j is a good thing. It was this very situation that got me to
> investigate log4j in the first place.  I was using IBM's Component
> Broker which uses JRAS (an ancient version of IBM's JLOG).  At first I
> was happy that I was getting a log package for free.  JRAS was there by
> virtue of my app running in Component Broker.
> 
> But as new versions of JRAS came out, I realized I couldn't use them
> without risking an incompatibility with Component Broker (which relied
> on an earlier version).  I was essentially stuck with whatever version
> my appserver was using.  Since logging tools tend to release more often
> than app servers, this significantly compromised the logging
> effectiveness.  By using a tool like log4j that is not part of the app
> server, I can choose to upgrade (or choose not to) whenever I want.  I
> can also tweak the code for certain specific needs without having to
> worry about impact to the app server.

My understanding is that servlet API 2.3 addresses this issue by saying
that app class loaders NOT delegate class loading to the parent. The
following quote is from an article discussing changes in 2.3:

 
http://www.javaworld.com/javaworld/jw-01-2001/jw-0126-servletapi_p.html


Class loaders

Here's a small change with a big impact: In API 2.3, a servlet container
a.k.a. the server) will ensure that classes in a Web application not be
allowed to see the server's implementation classes. In other words, the
class loaders should be kept separate. 

That doesn't sound like much, but it eliminates the possibility of a
collision between Web application classes and server classes. That had
become a serious problem because of XML parser conflicts. Each server
needs an XML parser to parse web.xml files, and many Web applications
these days also use an XML parser to handle reading, manipulation, and
writing of XML data. If the parsers supported different DOM or SAX
versions, that could cause an irreparable conflict. The separation of
class scope solves this issue nicely. 


--
Anders Kristensen

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

Re: PriorityFilterMatch

[Anders Kristensen]

You cannot currently set per-appender filters via the
PropertyConfigurator. From the PropertyConfigurator javadoc
documentation:

The PropertyConfigurator does not handle the advanced configuration
features supported by the DOMConfigurator such as support for
sub-classing of the Priority class, Filters, custom ErrorHandlers,
nested appenders such as the AsyncAppender, etc.

Anders


[EMAIL PROTECTED] wrote:
> 
> I've got atrouble when using a PriorityFilterMatch on an Appender.
> 
> I want to log INFO priority into a file (and only this priority), and log
> all the priorities on the console...
> 
> I use this property file :
> 
> # configure the root Category
> log4j.rootCategory=DEBUG, A1, A2
> 
> #configure the A1 appender
> log4j.appender.A1=org.apache.log4j.FileAppender
> log4j.appender.A1.File=test.html
> log4j.appender.A1.layout=org.apache.log4j.HTMLLayout
> log4j.appender.A1.Append=false
> log4j.appender.A1.filter=org.apache.log4j.varia.PriorityMatchFilter
> log4j.appender.A1.filter.PriorityToMatch=INFO
> log4j.appender.A1.filter.AcceptOnMatch=true
> 
> #configure the A2 appender
> log4j.appender.A2=org.apache.log4j.ConsoleAppender
> log4j.appender.A2.layout=org.apache.log4j.PatternLayout
> log4j.appender.A2.layout.ConversionPattern=%p: %c - %m%n
> log4j.appender.A1.Threshold=DEBUG
> 
> With this property file, DEBUG informations also appears in test.html
> 
> Any idea ???
> 
>  Michael Poisson
> 
> PS : I've got the same comportement using the 1.1beta version
> 
> --
> DISCLAIMER:
> This e-mail contains proprietary information some or all of which may be
> legally privileged. It is for the intended recipient only. If an addressing
> or transmission error has misdirected this e-mail, please notify the author
> by replying to this e-mail. If you are not the intended recipient you must
> not use, disclose, distribute, copy, print, or rely on this e-mail.
> 
> -
> 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: SocketServer and Subclassing

[Anders Kristensen]

The SocketServer is quite simple and is mainly intended as sample code
which you can use to implement your own remote logging server. Making it
use DOMConfigurator should be straightforward.

Anders

"Rouwendaal, Fernand" wrote:
> 
> Hi there,
> 
> I have extended log4j with a TRACE Priority and with a SUNSDK14 Category
> (accepting the current proposed SDK 1.4 logging messages).
> -> I can only make use of these extensions using a DOMConfigurator.
> 
> Now I want to make use of a SocketServer.
> -> The SocketServer only runs with a PropertyConfigurator (not with a
> DOMConfigurator). Thus: The SocketServer does not accept my extnesions.
> 
> Is there any possibility of letting the SocketServer making use of my
> extensions ?
> 
> TIA !
> 
> - Fernand.
> 
> -
> 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: 1.1beta not initializing properly

[Anders Kristensen]

Someone else got caught out by specifying a log file in a directory
which doesn't exist as log4j won't create the directory for you and so
won't log. Could this be your problem here?

Anders


Marcus Ahnve wrote:
> 
> My mistake, I considered our setup pretty basic but of course, here it
> is.
> 
> #
> # Set options for appender named "A1".
> #
> 
> log4j.appender.A1  = org.apache.log4j.FileAppender
> log4j.appender.A1.File = log/lecandolog.log
> log4j.appender.A1.layout   = org.apache.log4j.PatternLayout
> log4j.appender.A1.layout.ContextPrinting   = enabled
> log4j.appender.A1.layout.ConversionPattern = %d [%t] %-5p %c %x - %m\n
> 
> # Root category set to ERROR using the A1 appender defined above.
> 
> log4j.rootCategory = ERROR, A1
> log4j.configDebug  = true
> 
> /Marcus
> 
> Anders Kristensen wrote:
> >
> > Marcus,
> >
> > You'd get better responses if you include your log4j.properties file.
> >
> > Marcus Ahnve wrote:
> > >
> > > When trying out the new beta with the very same log4j.properties as
> > > we've succesfully used with 1.0.4, I cannot get the rootCategory
> > > settings to work. Instead I get a message telling me that no appenders
> > > were found for whatever class.
> > >
> > > I've tried to find information on changes regarding this in the new
> > > version without success. Has anybody else seen this, or have I missed
> > > something?
> > >
> > > /Marcus
> 
> --
> Marcus Ahnve  email: [EMAIL PROTECTED]
> Lecando AB   Office: +46-(0)8-634 94 18
> Sweden   Mobile: +46-(0)70-462 19 18
> www.lecando.comICQ#: 4564879
> 
> -
> 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: Build log4j is a PITA

[Anders Kristensen]

Robert Burrell Donkin wrote:
> 
> the main advantage of this is that the build doesn't depend on the user's classpath 
>environmental variable. this makes the build
> much more portable.

But then log4j has to ship with all libraries it depends on - which is
quite a few. And also, there is no guarantee that the versions of these
libraries match what log4j users use themselves, i.e. log4j compilation
could work and then using resulting jar files might fail because they
depend on newer versions of libs.

--
Anders Kristensen

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

Re: 1.1beta not initializing properly

[Anders Kristensen]

Marcus,

You'd get better responses if you include your log4j.properties file.

Marcus Ahnve wrote:
> 
> When trying out the new beta with the very same log4j.properties as
> we've succesfully used with 1.0.4, I cannot get the rootCategory
> settings to work. Instead I get a message telling me that no appenders
> were found for whatever class.
> 
> I've tried to find information on changes regarding this in the new
> version without success. Has anybody else seen this, or have I missed
> something?
> 
> /Marcus
> --
> Marcus Ahnve  email: [EMAIL PROTECTED]
> Lecando AB   Office: +46-(0)8-634 94 18
> Sweden   Mobile: +46-(0)70-462 19 18
> www.lecando.comICQ#: 4564879
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
Anders Kristensen

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

Re: backend l10n

[Anders Kristensen]

Oh yes, of course. Thanks for the reminder and good luck with logging in
turkish or whatever.

Anders

Luke Blanshard wrote:
> 
> Anders Kristensen wrote:
> 
> > "Johnson, Clay" wrote:
> > >
> > > L as in Localization.  It just looks like a Turkish I :)
> >
> > It was the 0 (zero) I was wondering about. Shouldn't it be '8'?
> 
> The significance of the number is: the number of characters between the first and
> last letters of the word.  Someone came up with "i18n" as a shorthand for
> "internationalization", because there are 18 characters between the i and the n.
> The "l10n" is the analogous formation for "localization".  There are only 10
> characters between the l and the n in that word.
> 
> Luke

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

Re: backend l10n

[Anders Kristensen]

"Johnson, Clay" wrote:
> 
> L as in Localization.  It just looks like a Turkish I :)

It was the 0 (zero) I was wondering about. Shouldn't it be '8'?

> 
> A colleague thinks the answer may involve ObjectRenderer.  There's little
> said about it in the javadoc.  Is it, or can it be used as a plugin to alter
> the behavior of a predefined appender?  If so, could I use it perform l10n
> in the appender(s)?

Yes you probably could. Your ObjectRenderer would know about your
special type of Objects and would convert to String in locale specific
manner.

> 
> > -Original Message-
> > From: Anders Kristensen [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 06, 2001 3:29 PM
> > To: LOG4J Users Mailing List
> > Subject: Re: backend l10n
> >
> >
> > Do you not mean "l18n"?
> >
> > "Johnson, Clay" wrote:
> > >
> > > Folks,
> > >
> > > I have a requirement to defer l10n processing to appenders,
> > rather than at
> > > the publisher of the log event, in order that different
> > appenders may
> > > localize the same event according to different locales.
> > Since the l10n
> > > methods in Category rely on preregistered ResourceBundles,
> > that doesn't
> > > work. Furthermore, with only a cursory look at the
> > internals, it appears
> > > log4j converts the message Object to a String to construct
> > a LoggingEvent
> > > *prior* to distributing that to all appenders.  If that is
> > true, I worry
> > > whether my requirement can be met without substantial
> > > modification/extension.
> > >
> > > One approach is to marshall my ResourceBundle name, key,
> > and replaceables
> > > into a string, and then implement my own Appender that
> > unpacks these,
> > > localizes according to *its* Locale (determined at
> > construction), and then
> > > proceeds to log the localized String.  The immediate
> > concern with this
> > > approach is apparent forfeiture of all existing Appender
> > functionality that
> > > I otherwise want to leverage, as well as Layout processing,
> > since I would
> > > have co-opted it to marshall my Object.
> > >
> > > Please tell me there's a simpler way to do this that
> > doesn't up-end the
> > > framework.
> >
> > You should be OK. Just don't use the String which has already been
> > constructed or  else use it a as a key into the resource bundles (like
> > Category does). Judging from what you're saying you're planning on
> > passing in non-Strng object which you'll use in Appenders/Layouts to
> > create localized log messages in some way.  The LoggingEvent now
> > contains the original Object *in addition* to the String
> > version of same
> > Object so you can just use the Object.
> >
> > >
> > > Thanks,
> > > Clay
> >
> > --
> > Anders Kristensen
> >
> > -
> > 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]

--
Anders Kristensen

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

Re: backend l10n

[Anders Kristensen]

Do you not mean "l18n"?

"Johnson, Clay" wrote:
> 
> Folks,
> 
> I have a requirement to defer l10n processing to appenders, rather than at
> the publisher of the log event, in order that different appenders may
> localize the same event according to different locales.  Since the l10n
> methods in Category rely on preregistered ResourceBundles, that doesn't
> work. Furthermore, with only a cursory look at the internals, it appears
> log4j converts the message Object to a String to construct a LoggingEvent
> *prior* to distributing that to all appenders.  If that is true, I worry
> whether my requirement can be met without substantial
> modification/extension.
> 
> One approach is to marshall my ResourceBundle name, key, and replaceables
> into a string, and then implement my own Appender that unpacks these,
> localizes according to *its* Locale (determined at construction), and then
> proceeds to log the localized String.  The immediate concern with this
> approach is apparent forfeiture of all existing Appender functionality that
> I otherwise want to leverage, as well as Layout processing, since I would
> have co-opted it to marshall my Object.
> 
> Please tell me there's a simpler way to do this that doesn't up-end the
> framework.

You should be OK. Just don't use the String which has already been
constructed or  else use it a as a key into the resource bundles (like
Category does). Judging from what you're saying you're planning on
passing in non-Strng object which you'll use in Appenders/Layouts to
create localized log messages in some way.  The LoggingEvent now
contains the original Object *in addition* to the String version of same
Object so you can just use the Object.

> 
> Thanks,
> Clay

--
Anders Kristensen

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

Re: SocketServer & SocketAppender

[Anders Kristensen]

I don't know what your problem is but it's absolutely possible to use
SpcketAppender to log to a SocketServer on the local host.

Anders


John Brunton wrote:
> 
> Here is another newbie question:
> 
> Can one run the SocketServer class on the same machine (NT) as a client
> class trying to log to a SocketAppender?
> 
> I get the error: "Could not open ObjectInputStream..." that comes from
> SocketNode.
> 
> My log4j.properties file contains:
> 
> log4j.rootCategory=DEBUG, Root_Appender
> log4j.appender.Root_Appender=org.apache.log4j.net.SocketAppender
> log4j.appender.Root_Appender.RemoteHost="myserver"
> log4j.appender.Root_Appender.Port=8080
> log4j.appender.Root_Appender.LocationInfo=true
> 
> -
> 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: how to output line numbers ?

[Anders Kristensen]

Ivar,

Line numbers are inferred from a stack trace and as the format of these
is not standardized, line numbers are necessarily a best-effort
function. It happens to work for mosty JVMs, though. It would be helpful
if you could say what JVM you're using and give your configuration as
well as sample output.

Thanks,
Anders


Ivar Vasara wrote:
> 
> I've tried the following things to get method names & line numbers to output
> while debugging a servlet, with no luck..
> 
> a) disabled JIT by setting the environment variable JAVA_COMPILER to NONE
> (as is indicated in the FAQ)
> b) tried putting servlets in system classpath with log4j
> c) tried log4j.jar as part of the web app
> 
> Nothing seems to work.. is there something I'm missing ?
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
Anders Kristensen

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

Re: How to use Writer object instead of OutputString , when using log4j?

[Anders Kristensen]

The log4j "core" doesn't use output streams nor writers, individual
appenders do. I believe the appenders which ship as part of log4j does
indeed use Writers and not OutputStream. This is true, for example, for
FileAppender. Ultimately, however, characters are written using your
platforms default character encoding. If your platforms default encoding
was, say, UTF-8, then korean log messages written to a FileAppender
should appear as korean in UTF-8 encoded log files.

Anders


Kim Jongtae wrote:
> 
> Hi all.
> 
> My language is Korean.
>  I want to log Korean  messages using log4j. But in order that I
> logging any Korean messages  properly,
> I must convert the messages into 8859-1 charset , because log4j uses
> internally OutputStream, which
> converts characters into bytes according a specified encoding and
> writes them to a byte-output stream.
> 
> when I use character streams , for examples Writer or Reader , there
> is no conversion so I can log in
> my language.
> 
> How do I make the log4j using character stream class ?
> Is there class or method?  sample java source or modification for
> properties?
> 
> If you give me, I will thank for you
> 
> 
> 
> Bye.
> 
> 
>

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

Re: Why more set(....) APIs than get(....) APIs in log4j ?

[Anders Kristensen]

Ceki Gülcü wrote:
> 
> At 22:01 22.02.2001 +0100, Anders Kristensen wrote:
> >Jin,
> >
> >Funny you should ask, because the getters you ask for have actually been
> >applied to the log4j version in the CVS repository and will be included
> >in the next release.  However, we've been discussing the option of
> >changing the current option OptionHandler configuration strategy from
> >something based on
> >
> >  void setOption(String key, String value) { ... }
> >  String getOption(String key) { ... }
> >  String[] getOptionsStrings()
> >
> >to something based on regular Java setters and getters, e.g.
> >
> >  void setFilename(String name)
> >  String getFilename() { ... }
> >
> >and then use a Beans-like strategy or reflection or something to figure
> >out which parameters a log4j component knows about. That seems to be a
> >better approach but requires a bit more work.
> >
> >Anders
> 
> Anders,
> 
> I think that the getX/setX or bean paradigm is more widely accepted.
> We should probably go with that.

I tend to agree with that.

> The getOption methods are cool except that if they go into an
> official release it will damn hard to take them back. So if we
> decide to switch I think we should switch as soon as possible.

No argument there either. Also, I agree that there absolutely shouldn't
be two ways of configuring log4j components.

> I actually intend to release 1.1beta before this weekend though
> that is not a promise... What do you think? Ceki

Great. I'd like to work on the options bit but unfortunately there's no
chance I'll have time for it until a week from now.

--
Anders Kristensen

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

Re: Why more set(....) APIs than get(....) APIs in log4j ?

[Anders Kristensen]

Jin,

Funny you should ask, because the getters you ask for have actually been
applied to the log4j version in the CVS repository and will be included
in the next release.  However, we've been discussing the option of
changing the current option OptionHandler configuration strategy from
something based on

  void setOption(String key, String value) { ... }
  String getOption(String key) { ... }
  String[] getOptionsStrings()

to something based on regular Java setters and getters, e.g.

  void setFilename(String name)
  String getFilename() { ... }

and then use a Beans-like strategy or reflection or something to figure
out which parameters a log4j component knows about. That seems to be a
better approach but requires a bit more work.

Anders


Jin Zhao wrote:
> 
> Maybe the question sucks, but it is from problems i have to face at.
> 
> I am writting a web based application aiming at monitoring and controlling
> the logging behavior of our application server, which uses log4j in
> applicaitons code. The problem is, there are so many set(...) methods, but
> lacks related get(...) methods in log4j API, that make it hard to get run
> time information of logging.  The following are some examples.
> 
> 
> ==
> Appender.java:
> we have setErrorHandler(..),  setLayout(...),  but have no
> getErrorHandler() and getLayout().
> I really want to know what layout my appender is using at run time.
> 
> OptionHandler.java:
> We have "public void setOption(String option, String value)", but no
> "public String getOption(String key)" which return the option value
> as a String. Isn't it convennient that we can know the  file name of my
> appender by using something like getOpotion("FileOption") or the
> maxBackupIndex value by using getOtion("Max_Backup_Index_Option") ??
> 
> FileAppender.java:
> We have setFile(..),  but no getFile()
> 
> PatternLayout.java:
> we have setConversionPattern(..), but no getConversionPattern()
> 
> ==
> 
> Of course i can get some of these information from the configuration file.
> The problem is, run time logging behavior can change dynamically using those
> set(...), add()  and remove(..) methods, that make it not consisten with
> the config files. In addition, I want the config files to offer some default
> behavior when the appllications loaded up, but set/reset the logging
> behavior without changing the configuration files. If I really find one
> behavior is better to be written into the config file, I can save it.
> 
> I tried to add some get() stuff in the log4j code, and find that a  "public
> String getOption(String key)" method is really helpful in my application, it
> fulfills most of the get() tasks.
> 
> Is there any concerns related with these get() stuffs behind the log4j
> architecture ?
> 
> Thanks a lot.
> 
> Jin
> 
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
> 
>   
> 
>Part 1.2Type: application/ms-tnef
>Encoding: base64

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

Re: adding custom priorities

[Anders Kristensen]

Kitching Simon wrote:
> 
> Hi Jim,
> 
> Nice to see there *are* people using custom
> Priorities .. I thought I was alone for a while!
> 
> Just a few comments:
> 
> (a)
> with this approach, the custom category needs
> to be used like this:
> 
> TraceableCategory cat = (TraceableCategory)
>TraceableCategory.getInstance("catname");
> cat.trace("msg");
> 
> ie a cast is needed. This is not a big deal,
> but is a minor nuisance

What I've done is define a method other than getInstance which returns
the appropriate subclass, e.g. getTrace below:

  public class Trace extends Category {
public static Category getInstance(String name) {
return Category.getInstance(name, traceFactory);
}
public static Trace getTrace(String name) {
return (Trace) getInstance(name);
}
...
  }

> 
> (b)
> in your xml config file, you didn't specify a
> custom CategoryFactory. Doesn't this mean
> that the above cast to TraceableCategory
> will throw an exception, because the
> Category object was actually created as a
> normal org.apache.log4j.Category?
> 
> Your example shows how to explicitly set
> the category class for root, but it isn't feasable
> to set an explicit category class for every
> category...
> 
> I think it *might* be ok if you don't try to
> set any filtering level on categories in the
> config file, as then the only category created
> is the root category, but as soon as category-
> specific config features are specified, the
> Configurator needs to create the Category
> object, and will use the default factory unless
> an alternative "global" factory has been defined.

This is a pain but it's usually possible to avoid configuring the exact
Category that one is interested in, e.g. if your code needs a Trace
Category for com.example.foo.bar.MyClass then instead of configuring
MyClass you configure com.example.foo.bar. The config code will then
create a Category for that node in the hierarchy and your app code will
create a Trace object for com.example.foo.bar.MyClass.

A real solution would be to make it possible to specify the
CategoryFactory per category.

--
Anders Kristensen

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

Re: Failover logging possible in Log4J ?

[Anders Kristensen]

Anand,

You are free to do whatever you like in appenders. That includes
detecting lost connection to a database, say, and either attempt
reconnection (similar to what SocketAppender does) or reconfigure log4j
itself to log to a file instead. You have to write the custom code, e.g.
extend an existing Appender, that does this, though.

Anders 


Anand Prahlad wrote:
> 
> Hello all,
> 
> Is failover logging possible in Log4J ? I have rolled my own appender to log
> to a database (this is specific to my database schema for logging errors).
> Ordinarily, I want to log only to the database. In case of an error (i.e.
> database connection lost, database is down..etc..), I want to switch over to
> logging to a flat file. Logging to a flat file and to other appenders is not
> desirable in the particular architecture that we are developing ( I know
> Log4J gives us this capability of writing to all "registered" appenders at
> the same time).
> 
> Any ideas on how failover logging can be achieved using Log4J? Much
> appreciate input on this.
> 
> Regards,
> Anand
> 
>   
> 
>    Part 1.2Type: application/ms-tnef
>Encoding: base64

--
Anders Kristensen

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

RE: Static vs. non-static categories and inner classes

[Anders Kristensen]

> That brings up a good question: Does the parser that creates a
> hierarchy for Categories tokenize on a period only, or does it
> also understand $ as a seperator?  If not, then maybe
> Category.getInstance(Class clz) should translate a $ in a name
> to a period.

I don't think it should. Not only would it interfere with the
understated beauty of the code -:) but since inner classes are defined
(and probably also how they're usually implemented) in terms of a code
transformation to something without inner classes, it is perfectly
consistent to NOT to interpret Inner$Outer as having hierarchical
structure - the JVM sees it as a single class name.

--
Anders Kristensen

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

Re: PropertyConfigurator question

[Anders Kristensen]

John Volkar wrote:
> 
> Ahem, just a quick one.
> 
> Becareful if using this code as it's not quite right.  The
> .getAllAppenders() method does NOT seem to return null if there are no
> appenders on the root category (like the javadocs say it should).  It seems
> to return an instance of a log4j.helpers.NullEnumeration class instead.
> 
> Maybe someone should patch the javadocs please.  (Maybe this is just for the
> Root category, though?  hmmm)

No it's all Categories. I've removed the offending comment. Thanks.


> 
> Regards
> 
> John Volkar
> 
> -Original Message-
> From: Anders Kristensen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 30, 2001 8:17 AM
> To: LOG4J Users Mailing List
> Subject: Re: PropertyConfigurator question
> 
> Andy Kriger wrote:
> > [...]
> > What I want is a way to check if PropertyConfigurator is able to find
> > log4j.properties and if not, then and only then call
> > BasicConfigurator.configure() as a backup.
> >
> > Is this possible?
> 
> You can check whether at least one Category has been added to the
> default hierarchy or whether an appender has been added to the root
> category:
> 
>   public static boolean isLog4jConfigured() {
> Enumeration cats = Category.getCurrentCategories();
> Enumeration rootApps = Category.getRoot().getAllAppenders();
> return cats.hasMoreElements() || rootApps != null;
>   }
> 
> I haven't checked it but it ought to work.
> 
> <<-SNIP->>
> 
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
Anders Kristensen

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

Mail archives

[Anders Kristensen]

> 
> The log4j archives are at http://marc.theaimsgroup.com/. Ceki
> 

For MHonArc fans there are also archives at

  http://www.mail-archive.com/log4j-user@jakarta.apache.org/
  http://www.mail-archive.com/log4j-dev@jakarta.apache.org/

--
Anders Kristensen

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

Re: PropertyConfigurator question

[Anders Kristensen]

Andy Kriger wrote:
> [...]
> What I want is a way to check if PropertyConfigurator is able to find
> log4j.properties and if not, then and only then call
> BasicConfigurator.configure() as a backup.
> 
> Is this possible?

You can check whether at least one Category has been added to the
default hierarchy or whether an appender has been added to the root
category:

  public static boolean isLog4jConfigured() {
Enumeration cats = Category.getCurrentCategories();
Enumeration rootApps = Category.getRoot().getAllAppenders();
return cats.hasMoreElements() || rootApps != null;
  }

I haven't checked it but it ought to work.

> 
> Andy Kriger
> Triene Inc.
> 116 W23rd Street
> Suite 500
> New York, NY 10011
> 646.375.2364 (W)
> 646.298.5493 (M)
> 
>   
> 
>Part 1.2Type: application/ms-tnef
>Encoding: base64

--
Anders Kristensen

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