I've had similar requirements to you, as I understand them, to provide
centralised logging capability for an enterprise system, and to supply
additional attributes with logging messages.
Due to time constraints, I did not implement the additional attributes
(which included user name, application name, source hostname), however I did
implement a central logging server on log4j 0.8.2, using a custom XML
message format over JMS Queue transport.
The clients logged to the logging server using an XML/JMS appender which I
provided, then the logging server received the messages and logged to a
variety of server side appenders. The clients included batch programs which
were distributed around the server side.
The reason for XML rather than Java serialisation was to allow the
possibility of logging from non-Java components.
My XML/JMS appender extracted information from the LoggingEvent and
generated an XML message from it.
For this type of application there is a need to leave the final rendering
process to the server side. One could view Java serialisation (or XML
"serialisation") as a rendering process, however there needs to be an
"unrender" operation which is the inverse of rendering, and converts a
String or byte array back to a LoggingEvent.
I also had the need for delay of internationalisation to the server side, so
that i18n could be done in the locale of the viewer rather than the
originator, however this requirement went away and was not met. This again
implies postponing the final rendering to server side.
I envisaged writing logging data at server side to database via a JDBC
appender, then providing a separate viewer application which played back the
database and rendered using the locale of the viewer.
Although I haven't looked closely at log4j for some time, it may be that
some of these requirements are still not met, at least not without
significant bespoking.
Regarding JMS vs socket transport, JMS worked for us but might be too heavy
duty for a large number of clients. If you have firewalls then you may be
looking at HTTP or SMTP, probably with batched transfer of events.
Andrew
[EMAIL PROTECTED]
-----Original Message-----
From: Anders Kristensen [mailto:[EMAIL PROTECTED]]
Sent: 30 July 2001 17:05
To: LOG4J Users Mailing List
Subject: Re: Design: How to do the following with Log4j
[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. Mulle
> 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
> <akristensen@dynami To: LOG4J Users Mailing
List <[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 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]
>
> ---------------------------------------------------------------------
> 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]
********************************************************************************************
" This message contains information that may be privileged or confidential and
is the property of the Cap Gemini Ernst & Young Group. It is intended only for
the person to whom it is addressed. If you are not the intended recipient, you
are not authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message ".
********************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
