On Feb 26, 2009, at 12:44 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
On Feb 25, 2009, at 7:35 AM, Ceki Gulcu wrote:
I was meaning to ask. Why do you need support from
LocationAwareLogger for argument arrays if you are going to use
logback-classic underneath SLF4J?
I'm not sure what you are
On Feb 26, 2009, at 12:44 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
On Feb 25, 2009, at 7:35 AM, Ceki Gulcu wrote:
I was meaning to ask. Why do you need support from
LocationAwareLogger for argument arrays if you are going to use
logback-classic underneath SLF4J?
I'm not sure what you are
As an alternative design, appenders doing serialization such as
SocketAppender and JMSQueue/JMSTopicAppender can delegate the
serialization transformation to a sub-component. This way, the
ILoggingEvent interface need not know about serialization at all. The
SDOAware interface can be thus remove
Joern Huxhorn wrote:
On 25.02.2009, at 19:33, Ceki Gulcu wrote:
The SDOAware interface contains a single method:
public interface SDOAware {
Serializable getSDO();
}
It's not necessary for the SDO to implement Serializable. This is only
necessary if serialization using ObjectOutputStre
Ralph Goers wrote:
On Feb 25, 2009, at 7:35 AM, Ceki Gulcu wrote:
I was meaning to ask. Why do you need support from LocationAwareLogger
for argument arrays if you are going to use logback-classic underneath
SLF4J?
I'm not sure what you are getting at here. The implementation I wrote
for
Ceki Gulcu skrev:
public interface ILoggingEvent extends SDOAware {
I would like to ask to you not to use abbreviations, as they tend to
grow to be the name normally used for the concept.
See for instance NDC and MDC. One is a stack and the other a map, but
only careful research reveals th
On Feb 25, 2009, at 7:35 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
I don't take offense at technical discussions on mailing lists. A
lot can get misinterpreted. Instead, I suggest you take a look at
the code and see if you think it is a horrible idea. What I'm
currently actually using,
On 25.02.2009, at 19:33, Ceki Gulcu wrote:
The SDOAware interface contains a single method:
public interface SDOAware {
Serializable getSDO();
}
I would like to continue working until we arrive at a situation
where LoggingEventSDO better insulated from changes in LoggingEvent
or sub-compo
Hello all,
Revision 2170, even if many classes were affected, is conceptually a minor
refactoring of the LoggingEvent class. LoggingEvent class now is an
implementation of the ILoggingEvent interface shown below:
public interface ILoggingEvent extends SDOAware {
public String getThreadNam
Jörn Huxhorn wrote:
Using Ralphs example:
logger.logEvent(EventData data)
Wouldn't it be possible to hide all that init and cleanup in the
logEvent method?
e.g. something like the following
void logEvent(EventData data) {
EventDataHolder.set(data);
info("whatever");
EventDataHolder.
Ceki Gulcu wrote:
> Ralph Goers wrote:
>>
>> I don't take offense at technical discussions on mailing lists. A lot can
get misinterpreted.
Good to hear.
>> Instead, I suggest you take a look at the code and see if you think it is
a horrible idea.
I will, but not right now. I'm pretty sure it's not
Joern Huxhorn wrote:
I'm wondering how others are using Logback... I've always enabled caller
data and can live with the fact that it's somewhat slower if actually
logging something but very fast if no log event is actually generated...
Computing caller data as a global option is an interesti
Ceki Gulcu wrote:
> Joern Huxhorn wrote:
> > I disagree. I just implemented an enhanced version of the log4j NDC
> > myself as you suggested on the SLF4J mailinglist. It's implemented
> quite
> > similar to the logback MDC but isn't serialized/used by any standard
> > appender. My multiplex-appende
Ralph Goers wrote:
I don't take offense at technical discussions on mailing lists. A lot
can get misinterpreted. Instead, I suggest you take a look at the code
and see if you think it is a horrible idea. What I'm currently actually
using, but would replace with this, does have more knowled
Joern Huxhorn wrote:
> I disagree. I just implemented an enhanced version of the log4j NDC
> myself as you suggested on the SLF4J mailinglist. It's implemented quite
> similar to the logback MDC but isn't serialized/used by any standard
> appender. My multiplex-appenders, on the other hand, *are*
On Feb 25, 2009, at 6:11 AM, Joern Huxhorn wrote:
I wasn't trying to say that Ralph is doing anything wrong and I
sincerely hope that he does not have that impression. I have no idea
about audit logging at all so both Ralph and you will probably know
very
well what you are doing.
He is usi
Ceki Gulcu skrev:
Thorbjoern,
Which data point in logging event are you talking about?
Well, all those that can change actually. Wouldn't that be the
arguments passed?
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
___
logback-dev mail
Ceki Gulcu wrote:
>
>
> Hello Joern,
>
>
> I see your hammer and screwdriver analogy. However, while the
> hammer-screwdriver analogy is reasonable and valid in the case of
> extending slf4j/logback-classic for auditing purposes, it is not
> *always* valid. Morre importantly, even if the analogy is
Thorbjoern,
Which data point in logging event are you talking about?
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
The prepareForDeferredProcessing() method in the LoggingEvent class
addresses that problem. Whenever a logging event is about to be
serialized or transferred to another thre
Ceki Gulcu skrev:
The prepareForDeferredProcessing() method in the LoggingEvent class
addresses that problem. Whenever a logging event is about to be
serialized or transferred to another thread, you, as an author of an
appender, are supposed to call
loggingEvent.prepareForDeferredProcessing().
Hello Joern,
I see your hammer and screwdriver analogy. However, while the
hammer-screwdriver analogy is reasonable and valid in the case of
extending slf4j/logback-classic for auditing purposes, it is not
*always* valid. Morre importantly, even if the analogy is valid, it
does not necessarily
On Feb 24, 2009, at 3:32 PM, Joern Huxhorn wrote:
Hi Ceki
On 24.02.2009, at 20:00, Ceki Gulcu wrote:
Joern,
Accepting parameters of type Object instead of String opens the
door for nasty bugs as you point out. At the same time, it also
constitutes an important extension point for logba
Joern Huxhorn skrev:
Hi Ceki, Thorbjoern and Maarten,
I'd like to encourage all of you to take a look at my LoggingEvent
implementation at
I don't have an opinion on the refactoring, but I'd like for the socket
server to platform agnostic (as I mentioned earlier, but I am voicing it
louder n
Hi Ceki
On 24.02.2009, at 20:00, Ceki Gulcu wrote:
Joern,
Accepting parameters of type Object instead of String opens the door
for nasty bugs as you point out. At the same time, it also
constitutes an important extension point for logback within the
limits imposed by the SLF4J API.
Darn. I started to implement this and discovered that
LocationAwareLogger doesn't have a method that accepts the object
array so I am stuck serializing the data anyway - unless you'd care to
add
public void log(Marker marker, String fqcn, int level, String message,
Object[] argArray, Thro
On 24.02.2009, at 17:41, Thorbjoern Ravn Andersen wrote:
Joern Huxhorn skrev:
The sole reason for compressing is because the network connection is
too slow. Does that hold here?
It would be nice if the server allowed for both compressed and
uncompressed transparently. Also gzipping is rat
Thorbjoern Ravn Andersen wrote:
Java programs generally create a lot of short lived objects and the
garbage collectors know very well how to deal with them. I suggest we
measure to see if there is a difference :) You probably have some very
large datasets?
Preliminary test show that ther
Joern,
Accepting parameters of type Object instead of String opens the door for nasty
bugs as you point out. At the same time, it also constitutes an important
extension point for logback within the limits imposed by the SLF4J API.
I think that the org.slf4j.Logger class should contain a war
Thank you for sharing this example which illustrates the point quite well.
Ralph Goers wrote:
Yes and no. The API would be a call like logger.logEvent(EventData
data); EventData is really just a Map with a few extra methods. Under
the hood the event data gets serialized to XML as the "mess
Joern Huxhorn skrev:
The sole reason for compressing is because the network connection is
too slow. Does that hold here?
It would be nice if the server allowed for both compressed and
uncompressed transparently. Also gzipping is rather slowish :)
Well, I'm using the benchmarked classes
On Feb 24, 2009, at 7:36 AM, Joern Huxhorn wrote:
Ceki Gulcu wrote:
Joern Huxhorn wrote:
Therefore I'd suggest to define void setArgumentArray(String[])
instead of void setArgumentArray(Object[]) (see
http://jira.qos.ch/browse/LBCLASSIC-45 )
As Ralf mentioned, under certain circumstances i
Hello,
I agree that the Memento is probably not necesarry for achieving backwards
compatibility.
Google Protocol Buffers (or ApaPche Thrift) could also be interesting :
* better performance than xml encoding/decoding (not yet tested it myself
though)
* you can update the message types without br
Ceki Gulcu wrote:
> Joern Huxhorn wrote:
>
> > I also still think that the LoggingEvent should not know about the
> logic
> > behind the transformation from the Object[] arguments to the String[]
> > arguments.
>
> I am quite puzzled by your line of thought expressed above. Looking at
> d.h.lilith.
Thorbjoern Ravn Andersen wrote:
If you write custom serializer/deserializer and keep a serialversion you
can do whatever you want :)
Indeed, custom serialization is probably the way to go.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logb
Joern Huxhorn wrote:
> I also still think that the LoggingEvent should not know about the logic
> behind the transformation from the Object[] arguments to the String[]
> arguments.
I am quite puzzled by your line of thought expressed above. Looking at
d.h.lilith.data.logging package, while the L
Thorbjoern Ravn Andersen wrote:
> Joern Huxhorn skrev:
>>
>> XML encoding *is* significantly slower, especially because gzipping
>> isn't just an option but a must if you take a look at the increase of
>> size in case of XML.
> The sole reason for compressing is because the network connection is
>
Joern Huxhorn skrev:
XML encoding *is* significantly slower, especially because gzipping
isn't just an option but a must if you take a look at the increase of
size in case of XML.
The sole reason for compressing is because the network connection is too
slow. Does that hold here?
It would
Ceki Gulcu skrev:
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
Hello all,
I would like to split/redesign the LoggingEvent object as follows:
Hi.
Could you elaborate on what you want to achieve? Makes it easier to
evaluate your suggestion.
One important goal is to better support int
I'm -1 on this recommendation. SLF4J and Logback require messages to
be Strings. I "cheat" in audit logging by passing a Map as one of the
parameters. Although the Map can be serialized and deserialized the
cost of doing that is very high when the Map is just being passed to a
local Appende
Hi Ceki, Thorbjoern and Maarten,
I'd like to encourage all of you to take a look at my LoggingEvent
implementation at http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith-data
, more specific the classes in http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith-data/logging/src/
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
Hello all,
I would like to split/redesign the LoggingEvent object as follows:
Hi.
Could you elaborate on what you want to achieve? Makes it easier to
evaluate your suggestion.
One important goal is to better support interoperability betwe
Ceki Gulcu skrev:
Hello all,
I would like to split/redesign the LoggingEvent object as follows:
Hi.
Could you elaborate on what you want to achieve? Makes it easier to
evaluate your suggestion.
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
_
Hi Maarteen,
Thus far, mutability/immutablity, localness/remoteness, and storability on disk
are aspects that we need to take into consideration. Are there other aspects?
Maarten Bosteels wrote:
Hello Ceki,
Seems like a good idea to me. But what about making a read-only
interface and a rea
Hello Ceki,
Seems like a good idea to me. But what about making a read-only interface
and a read-write interface.
interface ImmutableLoggingEvent {
// only getters
}
interface MutableLoggingEvent {
// getters and setters
}
LoggingEventMemento implements ImmutableLoggingEvent
LoggingEvent i
Hello all,
I would like to split/redesign the LoggingEvent object as follows:
interface ILoggingEvent {
String[] getArgumentArray();
CallerData[] getCallerData();
Level getLevel();
String getLoggerName();
Marker getMarker();
Map getMDCPropertyMap();
String getMessage();
String
45 matches
Mail list logo
