logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: LoggingEvent and XML transport protocol
Date Thu, 20 Mar 2003 17:39:29 GMT

To say the least, I am surprised by the conclusions because I am unable to 
follow the reasoning.

Why can't LoggingEvent be modified to accept setters and getters for 
various fields? What backward compatibility issues are there if you add 
methods but do not remove anything? Kinda lost here...



At 10:53 PM 3/19/2003 -0800, mwomack@apache.org wrote:
>Hi all, I am replying to this email to the dev email list because I think it
>is of general interest.
>
>I spent some time recently evangelizing Scott to convert his Chainsaw
>specific receiver code into the new general Receiver model, saying that he
>could take the xml his UDPAppender was generating and create LoggingEvents
>in a general UDPReceiver class.  But, this was incorrect.  It is currently
>impossible to generally create LoggingEvents from scratch (referring to
>arbitrary NDC, MDC, or other data).  This has come up before when discussing
>ways to augment LoggingEvent without affecting older versions.
>
>It has also come up recently, under the logging.apache.org discussion, that
>it would be great if there was a language/platform independent protocol for
>passing around logging events, XML being mentioned as a prime candidate.
>
>It is going to be hard to support this with the current LoggingEvent.  We
>need a way to create LoggingEvents from scratch with information that is
>passed in (ie via an xml protocol).  I like Scott's idea that LoggingEvent
>could become an interface and we could then have different implementations.
>One implementation would be like today where the LoggingEvent is created
>when messages are logged and use the local NDC/MDC, etc.  Another
>implementation could take some xml and fill in it's data from that.  But
>both would implement LoggingEvent and look the same LoggingEvent clients.
>
>This should be done in a manner that is compatible with the log4X family of
>libraries, if we choose to do it.  This might be a good starting point to
>bring them all together.
>
>Ideas?  Discussion?
>
>-Mark
>
> > -----Original Message-----
> > From: Scott Deboy [mailto:Scott.Deboy@VirtualDesign.Net]
> > Sent: Wednesday, March 19, 2003 10:29 PM
> > To: mwomack@apache.org
> > Subject: RE: Chainsaw screenshots
> >
> >
> > Hey Mark..I recall looking at LoggingEvent and realizing I
> > couldn't do it..
> >
> > Support for an XML-based logging event is definitely the key to
> > cross-language logging support, obviously.  Sockets - both TCP
> > and UDP - are the other least common denominator.  I have a
> > co-worker that wants to use my logging UI for a VB app she's working on.
> >
> > I told her to write a DLL that pushes socket data and conforms to
> > the LoggingEvent portion of the updated log4j.dtd and my app will
> > take it.  I'll either make a new receiver (SocketXMLReceiver) or
> > something.
> >
> > Keeping to a least common denominator of XML is important to me
> > and I want to find a way to support it.  Right now, I'm using the
> > EventDetails - that's why I brought up the
> > EventDetailSink/EventDetail issue in an earlier email.  I don't
> > care if LoggingEvent takes a Node in a constructor or if there is
> > some factory or builder pattern involved, but I want to be able
> > to convert the events to and from XML.  Exported loggingevents
> > should definitely be in xml format - in my opinion.
> >
> > So I'm stuck using EventDetail or something similar, or making an
> > XMLLoggingEvent..hmm..there's an idea..LoggingEvent could be an
> > interface.  XMLLoggingEvent or SerializedLoggingEvent could be
> > the concrete classes.
> >
> > Scott
> >
> > -----Original Message-----
> > From: mwomack@apache.org [mailto:mwomack@apache.org]
> > Sent: Wed 3/19/2003 10:11 PM
> > To:   Scott Deboy
> > Cc:
> > Subject:      RE: Chainsaw screenshots
> >
> > I think I may have led astray on a particular point...
> >
> > > Right now there are implementations of
> > > SocketReceiver, SocketHubReceiver, and JMSReceiver.  They happen to pass
> > > around LoggingEvent objects (received from the matching
> > > appenders), but that
> > > is not required.  We could implement a JDKLoggingReceiver that takes JDK
> > > logging events and creates log4j LoggingEvent objects from the
> > > information.
> > > You could write a UDPReceiver that takes the XML data your
> > UDPAppender and
> > > creates log4j LoggingEvents.
> >
> > In an ideal world, this would be the case.  But in the current
> > world, it is
> > impossible to create a new instance of a LoggingEvent that has
> > all the NDC,
> > MDC, Properties, etc.  This is because there is no constructor
> > that takes in
> > these items.  The current LoggingEvent assumes that it has access to the
> > these structures locally or that copies have been made (and can thus be
> > transported via serialization).
> >
> > Right now we are limited to transporting LoggingEvents via sockets, jms
> > topics, etc.  Eventually I believe the goal is to allow for transport via
> > xml or some other protocol, but not yet.
> >
> > Sorry about that.  Can your UDPAppender send LoggingEvents instead of xml,
> > or is the xml a requirement?
> >
> > -Mark
> >
> >
> >
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

--
Ceki 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


Mime
View raw message