I was also wondering why Maarten did not find packaging data useful.
Joern Huxhorn wrote:
On 18.03.2009, at 21:54, Maarten Bosteels wrote:
I agree. I've never been a fan of packaging data, not even in
stacktraces.
It actually helped us in our current project so I could be considered a
fan
On 18.03.2009, at 21:54, Maarten Bosteels wrote:
I agree. I've never been a fan of packaging data, not even in
stacktraces.
It actually helped us in our current project so I could be considered
a fan ;)
It was a case of jar-hell that was caused by a changed group- and
artifactId which
On Wed, Mar 18, 2009 at 9:38 PM, Ceki Gulcu wrote:
>
> I don't see packaging data being part of caller data. If it were, we
> would need configuration code to support this case, which would
> unnecessarily bloat the code. Just as importantly, the user would have
> to know how to enable/disable th
I don't see packaging data being part of caller data. If it were, we
would need configuration code to support this case, which would
unnecessarily bloat the code. Just as importantly, the user would have
to know how to enable/disable this feature. It's just not worth the
trouble.
If you really n
Hi,
No objections at all.
Looking at my .proto file it's indeed pretty obvious that CallerData and
StackTraceElement are quite similar :-)
http://code.google.com/p/firewood/source/browse/trunk/compare-formats/src/main/java/com/googlecode/firewood/protobuf/logging.proto
I've done some benchmarkin
On 18.03.2009, at 17:35, Ceki Gulcu wrote:
Joern Huxhorn wrote:
Extending StackTraceElement won't work because STE is a final class.
Good point.
Why don't you simply use StackTraceElementProxy instead of STE?
That way, it could - optionally - also contain ClassPackagingData.
As it sta
Joern Huxhorn wrote:
Extending StackTraceElement won't work because STE is a final class.
Good point.
Why don't you simply use StackTraceElementProxy instead of STE? That
way, it could - optionally - also contain ClassPackagingData.
As it stands, CallerData is almost identical to the St
Hello Ralph,
The LoggingEvent class changed to a large extent in SVN
trunk. Replacing CallerData with StackTraceElement is yet another
incompatible change. Worrying about backward compatibility for
CallerData and not for the rest would be pretty pointless.
Ralph Goers wrote:
The only concern I
On 18.03.2009, at 14:52, Ralph Goers wrote:
The only concern I would have is that it would break an existing
user's code to remove it. I realize the version is still
0.9.something, but at this point Logback is being used in
production, probably in lots of places.
What I would suggest is
The only concern I would have is that it would break an existing
user's code to remove it. I realize the version is still
0.9.something, but at this point Logback is being used in production,
probably in lots of places.
What I would suggest is to change all the Logback code to use
StackTr
Hello,
I would like to replace the CallerData class with
StackTraceElement. The two classes contain the same fields.
StackTraceElement is part of the JDK. I can think of no valid reason
to duplicate a class found in the JDK.
Comments/objections?
--
Ceki Gülcü
Logback: The reliable, generic, fa
11 matches
Mail list logo
