You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by mw...@apache.org on 2003/03/20 07:53:29 UTC
RE: LoggingEvent and XML transport protocol
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
RE: LoggingEvent and XML transport protocol
Posted by RB...@dtint.com.
"A level of indirection solves every problem in computer science"
<mw...@apache.org>
03/19/2003 11:53 PM
Please respond to "Log4J Developers List"
To: "Log4J Developers List" <lo...@jakarta.apache.org>
cc:
Subject: RE: LoggingEvent and XML transport protocol
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
RE: LoggingEvent and XML transport protocol
Posted by Ceki Gülcü <ce...@qos.ch>.
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