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 Paul Smith <ps...@aconex.com> on 2007/04/03 02:07:22 UTC
1.3 - A Line in the Sand
At some point we can no longer ignore the decision about where 1.3
should go.
I am beginning to think that we should scale back 1.3 to be less of
the planned revolution and more of a substantial-update-but-
completely-backward compatible (to a point).
We can then step back and think way beyond 1.3 and come up with a new
vision for what we think is important in enterprise logging.
Firstly, what do people think of this idea?
Secondly, what do people think is left to do before preparing for a
fully supported 1.3 release ?
Third, who in the dev community (not just committers) is prepared to
provide some effort in this regard.
cheers,
Paul
RE: 1.3 - A Line in the Sand
Posted by Gary Gregory <gg...@seagullsoftware.com>.
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Monday, April 02, 2007 10:11 PM
> To: Log4J Developers List
> Subject: Re: 1.3 - A Line in the Sand
>
> At 07:07 PM 4/2/2007, you wrote:
> >At some point we can no longer ignore the decision about where 1.3
> >should go.
> >
> >I am beginning to think that we should scale back 1.3 to be less of
> >the planned revolution and more of a substantial-update-but-
> >completely-backward compatible (to a point).
> >
>
> I think it's been said before that 1.3 may be more of a dead end than
> anything else. Some interesting things went into it, but the fact
> that it became so incompatible with Log4j-1.2.xx is a real
> problem. Is it worth a release or do we just leave it as-is, forever
> alpha, and move on to 2.0?
We currently use 1.3 Alpha-7 and it works pretty well for us, my preference as a user would be to clean up the current alpha for release as 1.3 or call it 2.0 if it is not binary compatible with the latest 1.2.14.
In general, I dislike "big bang" releases and favor instead release early, release often, a la XP.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Jess Holle <je...@ptc.com>.
Paul Smith wrote:
> On 05/04/2007, at 6:51 AM, Jess Holle wrote:
>> I didn't know about the MDC treatment -- I'll have to look into that.
>>
>> Otherwise, I knew that #2 and #3 were covered by the existing
>> Chainsaw. I just didn't want to give up any of that to get #1
>> covered -- and don't personally see any value in porting Chainsaw to
>> logback to achieve #1 either. The information (also news to me) that
>> we're really close to being able to just have Chainsaw use log4j
>> 1.2.x just solidifies that opinion -- though I'd be happy with
>> Chainsaw based upon a stable 1.4.x log4j as well. [We can debate
>> whether we could have a stable log4j 1.3.x and use that -- but at
>> this point it does not matter whether this is technically possible,
>> the 1.3.x stream has enough of a troubled history that a new version
>> # is really needed to clear the air if nothing else.]
> Jess, you can use Chainsaw to connect to applications using log4j1.2,
> seriously. I do it all the time. The _only_ thing that I appear to
> miss is that log4j1.2 binary serialization of LoggingEvents does not
> currently ship all the MDC value, so while the event appears fine
> inside Chainsaw, if you have juicy MDC values on an event, the MDC
> bits just don't appear. This is, to me, a feature I think log4j1.2 is
> a must have because, really, IMHO, Context is what enterprise logging
> is all about ("No Log Line is an Island").
I actually use Chainsaw with our 1.2.x applications.
Yes, I *sorely* miss the MDC handling.
I'd also like a clearer message about log4j 1.3.x. My downstream
customers will use Chainsaw, inevitably see log4j 1.3 alpha mentioned in
the jar downloads and ask why they're using alpha software (i.e. where's
the stable stuff) and/or why the rest of our product is using 1.2.x when
1.3.x is available. [Hopefully the same person does not ask both
questions at the same time without seeing the contradiction.]
I also agree, however, that getting log4j 1.2.x to ship all the MDC
values is more important. I also find this a really big gap.
> Now, the argument that Chainsaw is built on top of an alpha release is
> still sort of valid, but I think that's really a 'hidden' problem of
> Chainsaw, rather than anything that is restricting a user. To the end
> user, they really shouldn't care as long as it works.
It's not entirely hidden -- it's actually rather visible as part of the
initial load.
Otherwise it's not much of a real problem, though -- the MDC gap is more
critical.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Paul Smith <ps...@aconex.com>.
On 05/04/2007, at 6:51 AM, Jess Holle wrote:
> I didn't know about the MDC treatment -- I'll have to look into that.
>
> Otherwise, I knew that #2 and #3 were covered by the existing
> Chainsaw. I just didn't want to give up any of that to get #1
> covered -- and don't personally see any value in porting Chainsaw
> to logback to achieve #1 either. The information (also news to me)
> that we're really close to being able to just have Chainsaw use
> log4j 1.2.x just solidifies that opinion -- though I'd be happy
> with Chainsaw based upon a stable 1.4.x log4j as well. [We can
> debate whether we could have a stable log4j 1.3.x and use that --
> but at this point it does not matter whether this is technically
> possible, the 1.3.x stream has enough of a troubled history that a
> new version # is really needed to clear the air if nothing else.]
>
Jess, you can use Chainsaw to connect to applications using log4j1.2,
seriously. I do it all the time. The _only_ thing that I appear to
miss is that log4j1.2 binary serialization of LoggingEvents does not
currently ship all the MDC value, so while the event appears fine
inside Chainsaw, if you have juicy MDC values on an event, the MDC
bits just don't appear. This is, to me, a feature I think log4j1.2
is a must have because, really, IMHO, Context is what enterprise
logging is all about ("No Log Line is an Island").
Now, the argument that Chainsaw is built on top of an alpha release
is still sort of valid, but I think that's really a 'hidden' problem
of Chainsaw, rather than anything that is restricting a user. To the
end user, they really shouldn't care as long as it works.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Jess Holle <je...@ptc.com>.
I didn't know about the MDC treatment -- I'll have to look into that.
Otherwise, I knew that #2 and #3 were covered by the existing Chainsaw.
I just didn't want to give up any of that to get #1 covered -- and don't
personally see any value in porting Chainsaw to logback to achieve #1
either. The information (also news to me) that we're really close to
being able to just have Chainsaw use log4j 1.2.x just solidifies that
opinion -- though I'd be happy with Chainsaw based upon a stable 1.4.x
log4j as well. [We can debate whether we could have a stable log4j
1.3.x and use that -- but at this point it does not matter whether this
is technically possible, the 1.3.x stream has enough of a troubled
history that a new version # is really needed to clear the air if
nothing else.]
--
Jess Holle
Scott Deboy wrote:
>
> # 1 is relatively easy to achieve (it should be sufficient to add some
> constructors and accessors to loggingevent in the 1.2 stream)
>
> #2 is already there (sockethubreceiver, socketreceiver,
> logfilexmlreceiver, file/open xml files in the UI)
> #3 is already there - MDC entries show up as individual columns in the
> UI - NDC as a specific column
>
> mdc entries and NDC can be queried via the expression syntax - to
> filter on an MDC key, use:
> PROP.somekey = somevalue
> in search, refine-focus filter and colorizing filters
>
> See the tutorial for more info.
>
> Scott Deboy
> COMOTIV SYSTEMS
> 111 SW Columbia Street Ste. 950
> Portland, OR 97201
>
> Telephone: 503.224.7496
> Cell: 503.997.1367
> Fax: 503.222.0185
>
> sdeboy@comotivsystems.com
>
> www.comotivsystems.com
>
>
>
> -----Original Message-----
> From: Jess Holle [mailto:jessh@ptc.com]
> Sent: Wed 4/4/2007 1:29 PM
> To: Log4J Developers List
> Subject: Re: 1.3 - A Line in the Sand
>
> Ceki Gülcü wrote:
> >> I'd be keen to consider starting Chainsaw v3 from scratch along side
> >> any post-log4j1.3-type operation and build in exceptional support for
> >> enterprise log management, but I'm only one person, and I know many
> >> of us are incredibly busy, but we were so active there for a while I
> >> think of the potential of what we could achieve! :) From a Java
> >> point of view I think many of the Java 1.4+ network library, and
> >> java.util.concurrent stuff could be well used in a new logging
> package.
> > I would certainly be interested in Chainsaw v3. How about doing it in
> > logback?
> I'd really like to see a Chainsaw that:
>
> 1. Didn't use an alpha log4j library
> 2. Fully supported log4j output (i.e. socket appenders, log4j XML
> files, etc)
> 3. Gives first-class (native terminology) treatment to log4j log
> event fields (NDC, MDC, level, etc)
>
> If that's achieved via logback, I could actually care less.
>
> That said, I don't see using logback myself due to:
>
> 1. Use of String rather than Object messages
> * This allows messages to convey general structured data
> without having to hack some intervening string
> representation (e.g. for direct O-R mapping of structured
> log messages).
> 2. Overall apparent lack of attempt to maintain compatibility with
> log4j
> * I really want source and binary compatibility for the 90%
> "user code" case.
> * Beyond this, I have custom repository selectors, JMX MBeans
> that account for and handle multiple repositories, etc.
> o I'd give these up if the library fulfilled these roles
> completely adequately. The MBeans would actually be
> most difficult to give up as I really like mine :-)
>
> --
> Jess Holle
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: 1.3 - A Line in the Sand
Posted by Scott Deboy <sd...@comotivsystems.com>.
# 1 is relatively easy to achieve (it should be sufficient to add some constructors and accessors to loggingevent in the 1.2 stream)
#2 is already there (sockethubreceiver, socketreceiver, logfilexmlreceiver, file/open xml files in the UI)
#3 is already there - MDC entries show up as individual columns in the UI - NDC as a specific column
mdc entries and NDC can be queried via the expression syntax - to filter on an MDC key, use:
PROP.somekey = somevalue
in search, refine-focus filter and colorizing filters
See the tutorial for more info.
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax: 503.222.0185
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Jess Holle [mailto:jessh@ptc.com]
Sent: Wed 4/4/2007 1:29 PM
To: Log4J Developers List
Subject: Re: 1.3 - A Line in the Sand
Ceki G�lc� wrote:
>> I'd be keen to consider starting Chainsaw v3 from scratch along side
>> any post-log4j1.3-type operation and build in exceptional support for
>> enterprise log management, but I'm only one person, and I know many
>> of us are incredibly busy, but we were so active there for a while I
>> think of the potential of what we could achieve! :) From a Java
>> point of view I think many of the Java 1.4+ network library, and
>> java.util.concurrent stuff could be well used in a new logging package.
> I would certainly be interested in Chainsaw v3. How about doing it in
> logback?
I'd really like to see a Chainsaw that:
1. Didn't use an alpha log4j library
2. Fully supported log4j output (i.e. socket appenders, log4j XML
files, etc)
3. Gives first-class (native terminology) treatment to log4j log
event fields (NDC, MDC, level, etc)
If that's achieved via logback, I could actually care less.
That said, I don't see using logback myself due to:
1. Use of String rather than Object messages
* This allows messages to convey general structured data
without having to hack some intervening string
representation (e.g. for direct O-R mapping of structured
log messages).
2. Overall apparent lack of attempt to maintain compatibility with log4j
* I really want source and binary compatibility for the 90%
"user code" case.
* Beyond this, I have custom repository selectors, JMX MBeans
that account for and handle multiple repositories, etc.
o I'd give these up if the library fulfilled these roles
completely adequately. The MBeans would actually be
most difficult to give up as I really like mine :-)
--
Jess Holle
RE: 1.3 - A Line in the Sand
Posted by Scott Deboy <sd...@comotivsystems.com>.
One more clarification:
Chainsaw V2 uses log4j 1.3alpha internally because of log4j 1.3's support of receivers and new methods on LoggingEvent.
Chainsaw V2 can process events generated by -any- of the log4j 1.2 appenders, minus the limitations Paul mentioned re: serial incompatibility of LocationInfo and possibly MDC for log4j 1.2 SocketAppender.
Just wanted to make sure folks understood Chainsaw's log4j 1.3 dependencies are all internal, and you can use log4j 1.2 to generate events which can be processed in Chainsaw.
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax: 503.222.0185
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Jess Holle [mailto:jessh@ptc.com]
Sent: Wed 4/4/2007 1:29 PM
To: Log4J Developers List
Subject: Re: 1.3 - A Line in the Sand
Ceki G�lc� wrote:
>> I'd be keen to consider starting Chainsaw v3 from scratch along side
>> any post-log4j1.3-type operation and build in exceptional support for
>> enterprise log management, but I'm only one person, and I know many
>> of us are incredibly busy, but we were so active there for a while I
>> think of the potential of what we could achieve! :) From a Java
>> point of view I think many of the Java 1.4+ network library, and
>> java.util.concurrent stuff could be well used in a new logging package.
> I would certainly be interested in Chainsaw v3. How about doing it in
> logback?
I'd really like to see a Chainsaw that:
1. Didn't use an alpha log4j library
2. Fully supported log4j output (i.e. socket appenders, log4j XML
files, etc)
3. Gives first-class (native terminology) treatment to log4j log
event fields (NDC, MDC, level, etc)
If that's achieved via logback, I could actually care less.
That said, I don't see using logback myself due to:
1. Use of String rather than Object messages
* This allows messages to convey general structured data
without having to hack some intervening string
representation (e.g. for direct O-R mapping of structured
log messages).
2. Overall apparent lack of attempt to maintain compatibility with log4j
* I really want source and binary compatibility for the 90%
"user code" case.
* Beyond this, I have custom repository selectors, JMX MBeans
that account for and handle multiple repositories, etc.
o I'd give these up if the library fulfilled these roles
completely adequately. The MBeans would actually be
most difficult to give up as I really like mine :-)
--
Jess Holle
Re: 1.3 - A Line in the Sand
Posted by Jess Holle <je...@ptc.com>.
Ceki Gülcü wrote:
>> I'd be keen to consider starting Chainsaw v3 from scratch along side
>> any post-log4j1.3-type operation and build in exceptional support for
>> enterprise log management, but I'm only one person, and I know many
>> of us are incredibly busy, but we were so active there for a while I
>> think of the potential of what we could achieve! :) From a Java
>> point of view I think many of the Java 1.4+ network library, and
>> java.util.concurrent stuff could be well used in a new logging package.
> I would certainly be interested in Chainsaw v3. How about doing it in
> logback?
I'd really like to see a Chainsaw that:
1. Didn't use an alpha log4j library
2. Fully supported log4j output (i.e. socket appenders, log4j XML
files, etc)
3. Gives first-class (native terminology) treatment to log4j log
event fields (NDC, MDC, level, etc)
If that's achieved via logback, I could actually care less.
That said, I don't see using logback myself due to:
1. Use of String rather than Object messages
* This allows messages to convey general structured data
without having to hack some intervening string
representation (e.g. for direct O-R mapping of structured
log messages).
2. Overall apparent lack of attempt to maintain compatibility with log4j
* I really want source and binary compatibility for the 90%
"user code" case.
* Beyond this, I have custom repository selectors, JMX MBeans
that account for and handle multiple repositories, etc.
o I'd give these up if the library fulfilled these roles
completely adequately. The MBeans would actually be
most difficult to give up as I really like mine :-)
--
Jess Holle
Re: 1.3 - A Line in the Sand
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:09 AM 4/3/2007, Paul Smith wrote:
>My somewhat superficial scan over logback shows a lot of promise from
>an end user point of view. I would certainly be interested in
>exploring that as an option. This is where licenses, politics and
>marketing all come to a head which are never fun.
:-)
>* Is bringing logback into Apache something the logback community
>would even remotely consider? Ceki, I know you're watching, do you
>think that it might obtain wider exposure by coming under the
>logging.apache.org banner? Is that something that you've ever
>thought of? I totally respect the community logback has already
>established.
Yes, I have given it some thought. Logback would
certainly gain wider exposure coming under the
l.a.o. banner. However, I am more interested in
the log4j developer community. Perhaps log4j
developers interested in log4j 2.0 could join
logback? Not the same level of exposure, but the
challenge and the fun is there.
>* Would the Apache dev community even consider looking at that sort
>of proposal?
>
>Apache log4j has a decent 'brand' behind it, and many people are
>familiar with it and support it, but we've become stagnant, and
>perhaps people are moving on. The logback project, if 'absorbed' as
>a new log4j version could well gain bigger traction quickly purely
>because of that brand and revitalize logging.apache.org as a broader
>community (I'm thinking non-java languages here). What we want
>is a healthy dev community, and right now I'm not sure we(log4j) have
>one. Curt's been the only one doing anything recently.
Logback is advancing at a very nice pace. Any
absorption into Apache is likely to break some of
the momentum we currently have, albeit it is a possibility worth considering.
>I'd be keen to consider starting Chainsaw v3 from scratch along side
>any post-log4j1.3-type operation and build in exceptional support for
>enterprise log management, but I'm only one person, and I know many
>of us are incredibly busy, but we were so active there for a while I
>think of the potential of what we could achieve! :) From a Java
>point of view I think many of the Java 1.4+ network library, and
>java.util.concurrent stuff could be well used in a new logging package.
I would certainly be interested in Chainsaw v3. How about doing it in logback?
>Paul
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:34 PM 4/3/2007, Curt Arnold wrote:
>Unfortunately, log4j 1.3 development proceed for a substantial amount
>of time with little concern with compatibility with compatibility
>with log4j 1.2 and the primary developer of log4j 1.3 has left for
>other projects. We are left trying to remedy the situation we are
>in. There have definitely been incremental releases in the log4j
>1.2.x branch and may continue to be so, but the code is very dated
>and extremely difficult to modify without potential compatibility
>issues.
Little concern with compatibility, that is
certainly not correct. My concern is to produce
the best library possible within the constraints
imposed by the resources available. As such,
although important, backward compatibility is not
my ultimate yardstick. It is easy to qualify each
and every incompatible change as reckless.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:58 PM 4/3/2007, Jess Holle wrote:
>Cu
>For a 1.4.x or 2.0.x, I'm not so concerned about breaking extensions.
>
>I'm more concerned about breaking "application"
>code -- i.e. use of the logging APIs for logging
>and for configuration thereof, including
>sophisticated code that adds hierarchy
>listeners, uses logger repository selectors,
>etc, but not including custom appenders,
>layouts, etc. I would hope that any really
>worthwhile extensions would be ported by someone
>and could be upgraded along with log4j as
>needed, whereas application code is unlikely to
>be so malleable. I realize the distinction is
>somewhat arbitrary and I could understand some
>of the more sophisticated (weird?) application
>usages breaking as long as there was a suitable
>replacement for the old functionality that was
>broken in the process. "Normal" usage of log4j
>APIs that most applications stick to should not be broken, however.
+1
Other than myself, I am unaware of anyone else
with the same opinion. Others may agree, but they
usually don't express it as clearly as above.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Jess Holle <je...@ptc.com>.
Curt Arnold wrote:
> On Apr 3, 2007, at 9:33 AM, Jess Holle wrote:
>> Largely I won't disagree.
>>
>> That said, I think there is a point to having a new log4j version
>> that is almost entirely API (source and binary) compatible with log4j
>> 1.2.14, but:
>> Has finer-grained synchronization and eliminates some possibilities
>> that currently exist for deadlocks, etc.
>> Uses modern JVM features to reduce scalability bottlenecks, etc.
>> I think log4j 1.2.14 is "as good as it gets" (or needs to) for JVMs
>> up to Java 1.4, but that there should be a compatible option that is
>> optimized for Java 5 and higher (or at least assumes good
>> ThreadLocal, etc, and takes advantage of these at a bare minimum).
>>
>> When I say "almost entirely" I mean API compatible wherever possible
>> while attaining item #1 above at least. This may break some
>> extensions (3rd-party appenders, etc), but that seems like a
>> reasonable price to pay. These can be updated (as long as what's
>> needed to do so is clearly spelled out) or those needing them can
>> stay at 1.2.14.
> Any rework that addressed the synchronization and scalability issues
> would almost certainly break the (largely implied) contracts that
> extension appenders, layouts, etc depend upon. log4j 1.2.x made
> little or no attempts to control where log4j could be extended: very
> few classes if any are final and the implementation details are
> visible, and so anything but small feature additions can break some
> potential extension. I would expect that any attempt to address the
> synchronization issues would abandon any attempt to be compatible with
> existing extensions but could provide a shim that could be used to
> emulate the "client" portions of the log4j 1.2.x API.
For a 1.4.x or 2.0.x, I'm not so concerned about breaking extensions.
I'm more concerned about breaking "application" code -- i.e. use of the
logging APIs for logging and for configuration thereof, including
sophisticated code that adds hierarchy listeners, uses logger repository
selectors, etc, but not including custom appenders, layouts, etc. I
would hope that any really worthwhile extensions would be ported by
someone and could be upgraded along with log4j as needed, whereas
application code is unlikely to be so malleable. I realize the
distinction is somewhat arbitrary and I could understand some of the
more sophisticated (weird?) application usages breaking as long as there
was a suitable replacement for the old functionality that was broken in
the process. "Normal" usage of log4j APIs that most applications stick
to should not be broken, however.
> Use of ThreadLocal and other incremental improvements could be done in
> a log4j 1.x, but I don't know whether we'd want to do that as a 1.2.x
> or a log4j 1.4.
That's a good question. Version #'s are cheap, so in this regard, I'd
suggest such increment improvements go into a 1.4.x, so no one gets
upset when they find that some new 1.2.x version is not compatible with
the same ancient JVMs as 1.2.14 was -- unless, of course, the given
incremental improvement does not break such compatibility (either
outright or by producing a behavioral/performance regression in such old
JVMs).
>> Why the insistence on API compatibility? This would allow the vast
>> majority of developers to simply code for "log4j" and ignore 1.2.x
>> vs. 1.3.x or 2.0.x distinctions and thus avoids fracturing log4j's
>> mindshare. Instead deployers could simply decide on the version of
>> log4j that best met their needs, e.g. old JVM compatible or not, etc.
> Not sure I'm following. If a version implies compatibility with a
> previous version (only a minor revision in version number and same
> package names), then breaking existing clients that were perfectly
> legal and function with the earlier versions is extremely bad form.
> See http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs.
> Basically for log4j 2.0, I think that we are left with the "start over
> in a new package" approach. However, we could provide shim with a
> emulation of a subset of the old API that could be used at the
> client's own risk.
In the case where one has something strictly insisting on log4j 1.2.x
(and breaking with 2.0.x) and something requiring 2.0.x that you want in
the same classloader, you're absolutely right, of course. Do we feel
that this use case is likely? If so, we should do as you say.
What I'm looking for is that the 90% usage case, i.e. most of the
methods of Logger, Level, and a few other critical classes, remain "as
is" -- that could be done via a "shim" as you put it. One could provide
a shim. If the key "90% case" APIs are kept "as is" except under a
different package name, then a simple mass replace could convert source
code and remove need for the shim. The shim could still be useful for
interaction with old libraries to which you had no source (or no desire
to rebuild) in many cases, though -- i.e. many libraries wouldn't use
enough APIs or use log4j extensively enough to know the difference.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Curt Arnold <ca...@apache.org>.
On Apr 3, 2007, at 9:33 AM, Jess Holle wrote:
> Largely I won't disagree.
>
> That said, I think there is a point to having a new log4j version
> that is almost entirely API (source and binary) compatible with
> log4j 1.2.14, but:
> Has finer-grained synchronization and eliminates some possibilities
> that currently exist for deadlocks, etc.
> Uses modern JVM features to reduce scalability bottlenecks, etc.
> I think log4j 1.2.14 is "as good as it gets" (or needs to) for JVMs
> up to Java 1.4, but that there should be a compatible option that
> is optimized for Java 5 and higher (or at least assumes good
> ThreadLocal, etc, and takes advantage of these at a bare minimum).
>
> When I say "almost entirely" I mean API compatible wherever
> possible while attaining item #1 above at least. This may break
> some extensions (3rd-party appenders, etc), but that seems like a
> reasonable price to pay. These can be updated (as long as what's
> needed to do so is clearly spelled out) or those needing them can
> stay at 1.2.14.
>
Any rework that addressed the synchronization and scalability issues
would almost certainly break the (largely implied) contracts that
extension appenders, layouts, etc depend upon. log4j 1.2.x made
little or no attempts to control where log4j could be extended: very
few classes if any are final and the implementation details are
visible, and so anything but small feature additions can break some
potential extension. I would expect that any attempt to address the
synchronization issues would abandon any attempt to be compatible
with existing extensions but could provide a shim that could be used
to emulate the "client" portions of the log4j 1.2.x API.
Use of ThreadLocal and other incremental improvements could be done
in a log4j 1.x, but I don't know whether we'd want to do that as a
1.2.x or a log4j 1.4.
> Why the insistence on API compatibility? This would allow the vast
> majority of developers to simply code for "log4j" and ignore 1.2.x
> vs. 1.3.x or 2.0.x distinctions and thus avoids fracturing log4j's
> mindshare. Instead deployers could simply decide on the version of
> log4j that best met their needs, e.g. old JVM compatible or not, etc.
>
Not sure I'm following. If a version implies compatibility with a
previous version (only a minor revision in version number and same
package names), then breaking existing clients that were perfectly
legal and function with the earlier versions is extremely bad form.
See http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs.
Basically for log4j 2.0, I think that we are left with the "start
over in a new package" approach. However, we could provide shim with
a emulation of a subset of the old API that could be used at the
client's own risk.
On Apr 3, 2007, at 12:03 PM, Gary Gregory wrote:
>
> We currently use 1.3 Alpha-7 and it works pretty well for us, my
> preference as a user would be to clean up the current alpha for
> release as 1.3 or call it 2.0 if it is not binary compatible with
> the latest 1.2.14.
Rebranding log4j 1.3 as log4j 2.0 and then having log4j 3.0 as the
designed for JDK 1.5+ and fine grained concurrency release was toyed
with a few years ago, but the consensus was that log4j could only
pull off one big API incompatible release and not two successive
ones. Would be interesting to know what features you are using in
log4j 1.3 and whether they could be backported to log4j 1.2.
>
> In general, I dislike "big bang" releases and favor instead release
> early, release often, a la XP.
>
Unfortunately, log4j 1.3 development proceed for a substantial amount
of time with little concern with compatibility with compatibility
with log4j 1.2 and the primary developer of log4j 1.3 has left for
other projects. We are left trying to remedy the situation we are
in. There have definitely been incremental releases in the log4j
1.2.x branch and may continue to be so, but the code is very dated
and extremely difficult to modify without potential compatibility
issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Jess Holle <je...@ptc.com>.
Largely I won't disagree.
That said, I think there is a point to having a new log4j version that
is almost entirely API (source and binary) compatible with log4j 1.2.14,
but:
1. Has finer-grained synchronization and eliminates some
possibilities that currently exist for deadlocks, etc.
2. Uses modern JVM features to reduce scalability bottlenecks, etc.
I think log4j 1.2.14 is "as good as it gets" (or needs to) for JVMs up
to Java 1.4, but that there should be a compatible option that is
optimized for Java 5 and higher (or at least assumes good ThreadLocal,
etc, and takes advantage of these at a bare minimum).
When I say "almost entirely" I mean API compatible wherever possible
while attaining item #1 above at least. This may break some extensions
(3rd-party appenders, etc), but that seems like a reasonable price to
pay. These can be updated (as long as what's needed to do so is clearly
spelled out) or those needing them can stay at 1.2.14.
Why the insistence on API compatibility? This would allow the vast
majority of developers to simply code for "log4j" and ignore 1.2.x vs.
1.3.x or 2.0.x distinctions and thus avoids fracturing log4j's
mindshare. Instead deployers could simply decide on the version of
log4j that best met their needs, e.g. old JVM compatible or not, etc.
--
Jess Holle
P.S. Okay, the ability to add a listener to a repository for log level
changes (as per log4j 1.3's last iterations) would be really nice. I'm
not against added bits like this.
Noel Grandin wrote:
> Hi
>
> I'm just an end-user of log4j, so I have no perspective on the internal
> dev issues.
>
> But from the POV of a programmer who uses log4j in many projects, I have
> to say that it's pretty great the way it is!!
>
> It may simply be that log4j as it currently stands is good enough for
> the vast majority of projects, hence the lack of interest in improving it.
>
> I like log4j - it's pretty clean, robust, easy to use, and doesn't have
> vast quantities of complexities for corner cases that most people never see.
>
> Regards and thanks for the great work!
> -- Noel Grandin
>
> Disclaimer: http://www.peralex.com/disclaimer.html
Re: 1.3 - A Line in the Sand
Posted by Noel Grandin <no...@peralex.com>.
Hi
I'm just an end-user of log4j, so I have no perspective on the internal
dev issues.
But from the POV of a programmer who uses log4j in many projects, I have
to say that it's pretty great the way it is!!
It may simply be that log4j as it currently stands is good enough for
the vast majority of projects, hence the lack of interest in improving it.
I like log4j - it's pretty clean, robust, easy to use, and doesn't have
vast quantities of complexities for corner cases that most people never see.
Regards and thanks for the great work!
-- Noel Grandin
Disclaimer: http://www.peralex.com/disclaimer.html
Re: 1.3 - A Line in the Sand
Posted by Paul Smith <ps...@aconex.com>.
>
> I think it's been said before that 1.3 may be more of a dead end
> than anything else. Some interesting things went into it, but the
> fact that it became so incompatible with Log4j-1.2.xx is a real
> problem. Is it worth a release or do we just leave it as-is,
> forever alpha, and move on to 2.0?
>
From a Chainsaw point of view a lot of work on creating good
Appender->Receiver stuff was done, and as I setup a decent
environment for our QA and Ops team to use Chainsaw through a
firewall (port forwarding) while our app is using log4j 1.2.14, I'm
beginning to see a dilemma. serialized LoggingEvents from 1.2 just
don't contain lots of info coming out the other end. I then asked
myself the question "Should we upgrade our app to use log4j 1.3", and
I honestly couldn't say what the quality was, hence the line-in-the-
sand email.
> >We can then step back and think way beyond 1.3 and come up with a new
> >vision for what we think is important in enterprise logging.
> >
> >Firstly, what do people think of this idea?
> >
>
> As long as we're considering things that have been ignored for a
> while, what is our official take on Logback? It's basically a
> realization of what Log4j-1.3 was supposed to be, no? Do we really
> have plans to best it as Log4j-2.0? I'm not saying we don't. I'm
> just asking the question. And what are we going to do about
> SLF4J? It's gained significant acceptance and we've punted on how
> we are going to approach it; implement it directly, write a wrapper
> for it (actually, this has already been done by the SLF4J team), or
> ignore it altogether. So far, we've chosen the latter as the path
> of least resistance.
>
My somewhat superficial scan over logback shows a lot of promise from
an end user point of view. I would certainly be interested in
exploring that as an option. This is where licenses, politics and
marketing all come to a head which are never fun.
* Is bringing logback into Apache something the logback community
would even remotely consider? Ceki, I know you're watching, do you
think that it might obtain wider exposure by coming under the
logging.apache.org banner? Is that something that you've ever
thought of? I totally respect the community logback has already
established.
* Would the Apache dev community even consider looking at that sort
of proposal?
Apache log4j has a decent 'brand' behind it, and many people are
familiar with it and support it, but we've become stagnant, and
perhaps people are moving on. The logback project, if 'absorbed' as
a new log4j version could well gain bigger traction quickly purely
because of that brand and revitalize logging.apache.org as a broader
community (I'm thinking non-java languages here). What we want
is a healthy dev community, and right now I'm not sure we(log4j) have
one. Curt's been the only one doing anything recently.
I'd be keen to consider starting Chainsaw v3 from scratch along side
any post-log4j1.3-type operation and build in exceptional support for
enterprise log management, but I'm only one person, and I know many
of us are incredibly busy, but we were so active there for a while I
think of the potential of what we could achieve! :) From a Java
point of view I think many of the Java 1.4+ network library, and
java.util.concurrent stuff could be well used in a new logging package.
>
> Do we want to "fully support" 1.3 or just move on? Log4j-1.3 is
> much larger than 1.2 because of, among other things, Joran. Joran
> in 1.3 was Ceki's brainchild and continued development of it has
> long since moved to Logback. I'd be more comfortable letting
> Logback developers maintain the official version and use it instead
> of maintaining it ourselves. I can't recall where I read it, but I
> believe it was stated that Joran could be used in other projects,
> separate from Logback. Of course, then why not just use Logback?
> Unless people are truly prepared to put in the time to figure out
> what the future of Log4j should be (and implement it), I'm afraid
> that Log4j-1.2.xx is the end of the line, though I'm completely
> open to being proved wrong.
>
What you say certainly seems possible. If we're not careful, the
log4j project could dwindle into nothing (not that that's a problem,
just sad).
> >Third, who in the dev community (not just committers) is prepared to
> >provide some effort in this regard.
> >
>
> That's the perennial problem, isn't it?
Indeed.
Paul
RE: 1.3 - A Line in the Sand
Posted by Gary Gregory <gg...@seagullsoftware.com>.
> -----Original Message-----
> From: Jess Holle [mailto:jessh@ptc.com]
> Sent: Wednesday, April 04, 2007 1:21 PM
> To: Log4J Developers List
> Subject: Re: 1.3 - A Line in the Sand
>
> Ceki Gülcü wrote:
> > At 07:10 AM 4/3/2007, Jacob Kjome wrote:
> >
> >> I think it's been said before that 1.3 may be more of a dead end than
> >> anything else. Some interesting things went into it, but the fact
> >> that it became so incompatible with Log4j-1.2.xx is a real problem.
> >> Is it worth a release or do we just leave it as-is, forever alpha,
> >> and move on to 2.0?
> > For most intents and purposes 1.3 is compatible with 1.2. I'd say that
> > 99.% percent of users will be able to use it out of the box. A very
> > small minority will need to make a few changes, either in their config
> > files or tweaking their extensions of log4j.
> I'd agree that this is *now* the case. Not that long ago (i.e. last
> calendar year when I first tried 1.3.x), 1.3.x had broken binary
> compatibility with fairly basic usage of 1.2.x APIs.
> > In my opinion, obsessing over total/absolute/100% backward
> > compatibility is a guaranteed recipe for project failure.
> I'd agree actually.
> >> As long as we're considering things that have been ignored for a
> >> while, what is our official take on Logback? It's basically a
> >> realization of what Log4j-1.3 was supposed to be, no? Do we really
> >> have plans to best it as Log4j-2.0? I'm not saying we don't. I'm
> >> just asking the question. And what are we going to do about SLF4J?
> >> It's gained significant acceptance and we've punted on how we are
> >> going to approach it; implement it directly, write a wrapper for it
> >> (actually, this has already been done by the SLF4J team), or ignore
> >> it altogether. So far, we've chosen the latter as the path of least
> >> resistance.
> > Contrary to UGLI, SLF4J API forces messages to be of type String (not
> > Object). As NLOG4J has shown, you can get away with it, but it will
> > force users to recompile. On the other hand, natively implementing
> > SLF4J will work much better in presence of repo-selectors
> I noticed that SLF4J (and apparently logback at a glance) force messages
> to be of type String.
>
> This is a *huge* step backwards as I see it. There are some *really*
> compelling things that can be done by having Object messages -- apart
> from the simple (but useful) lazy invocation of toString().
I agree, typing a logging API to Object make sense. Our applications now count on this behavior and implement toString() methods as appropriate. IMO, it would be a step backwards for force a data type, String in this case, when it is not needed, especially considering that toString() is implemented in Object.
Gary
>
> --
> Jess Holle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: 1.3 - A Line in the Sand
Posted by Scott Deboy <sd...@comotivsystems.com>.
I agree - the ability to log objects instead of strings only provides some capabilities which aren't available otherwise - filters are an example (see reflectionfilter & mapfilter in 1.3alpha).
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax: 503.222.0185
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Jess Holle [mailto:jessh@ptc.com]
Sent: Wed 4/4/2007 1:20 PM
To: Log4J Developers List
Subject: Re: 1.3 - A Line in the Sand
Ceki G�lc� wrote:
> At 07:10 AM 4/3/2007, Jacob Kjome wrote:
>
>> I think it's been said before that 1.3 may be more of a dead end than
>> anything else. Some interesting things went into it, but the fact
>> that it became so incompatible with Log4j-1.2.xx is a real problem.
>> Is it worth a release or do we just leave it as-is, forever alpha,
>> and move on to 2.0?
> For most intents and purposes 1.3 is compatible with 1.2. I'd say that
> 99.% percent of users will be able to use it out of the box. A very
> small minority will need to make a few changes, either in their config
> files or tweaking their extensions of log4j.
I'd agree that this is *now* the case. Not that long ago (i.e. last
calendar year when I first tried 1.3.x), 1.3.x had broken binary
compatibility with fairly basic usage of 1.2.x APIs.
> In my opinion, obsessing over total/absolute/100% backward
> compatibility is a guaranteed recipe for project failure.
I'd agree actually.
>> As long as we're considering things that have been ignored for a
>> while, what is our official take on Logback? It's basically a
>> realization of what Log4j-1.3 was supposed to be, no? Do we really
>> have plans to best it as Log4j-2.0? I'm not saying we don't. I'm
>> just asking the question. And what are we going to do about SLF4J?
>> It's gained significant acceptance and we've punted on how we are
>> going to approach it; implement it directly, write a wrapper for it
>> (actually, this has already been done by the SLF4J team), or ignore
>> it altogether. So far, we've chosen the latter as the path of least
>> resistance.
> Contrary to UGLI, SLF4J API forces messages to be of type String (not
> Object). As NLOG4J has shown, you can get away with it, but it will
> force users to recompile. On the other hand, natively implementing
> SLF4J will work much better in presence of repo-selectors
I noticed that SLF4J (and apparently logback at a glance) force messages
to be of type String.
This is a *huge* step backwards as I see it. There are some *really*
compelling things that can be done by having Object messages -- apart
from the simple (but useful) lazy invocation of toString().
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Jess Holle <je...@ptc.com>.
Ceki Gülcü wrote:
> At 07:10 AM 4/3/2007, Jacob Kjome wrote:
>
>> I think it's been said before that 1.3 may be more of a dead end than
>> anything else. Some interesting things went into it, but the fact
>> that it became so incompatible with Log4j-1.2.xx is a real problem.
>> Is it worth a release or do we just leave it as-is, forever alpha,
>> and move on to 2.0?
> For most intents and purposes 1.3 is compatible with 1.2. I'd say that
> 99.% percent of users will be able to use it out of the box. A very
> small minority will need to make a few changes, either in their config
> files or tweaking their extensions of log4j.
I'd agree that this is *now* the case. Not that long ago (i.e. last
calendar year when I first tried 1.3.x), 1.3.x had broken binary
compatibility with fairly basic usage of 1.2.x APIs.
> In my opinion, obsessing over total/absolute/100% backward
> compatibility is a guaranteed recipe for project failure.
I'd agree actually.
>> As long as we're considering things that have been ignored for a
>> while, what is our official take on Logback? It's basically a
>> realization of what Log4j-1.3 was supposed to be, no? Do we really
>> have plans to best it as Log4j-2.0? I'm not saying we don't. I'm
>> just asking the question. And what are we going to do about SLF4J?
>> It's gained significant acceptance and we've punted on how we are
>> going to approach it; implement it directly, write a wrapper for it
>> (actually, this has already been done by the SLF4J team), or ignore
>> it altogether. So far, we've chosen the latter as the path of least
>> resistance.
> Contrary to UGLI, SLF4J API forces messages to be of type String (not
> Object). As NLOG4J has shown, you can get away with it, but it will
> force users to recompile. On the other hand, natively implementing
> SLF4J will work much better in presence of repo-selectors
I noticed that SLF4J (and apparently logback at a glance) force messages
to be of type String.
This is a *huge* step backwards as I see it. There are some *really*
compelling things that can be done by having Object messages -- apart
from the simple (but useful) lazy invocation of toString().
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:10 AM 4/3/2007, Jacob Kjome wrote:
>I think it's been said before that 1.3 may be
>more of a dead end than anything else. Some
>interesting things went into it, but the fact
>that it became so incompatible with Log4j-1.2.xx
>is a real problem. Is it worth a release or do
>we just leave it as-is, forever alpha, and move on to 2.0?
For most intents and purposes 1.3 is compatible
with 1.2. I'd say that 99.% percent of users will
be able to use it out of the box. A very small
minority will need to make a few changes, either
in their config files or tweaking their extensions of log4j.
In my opinion, obsessing over total/absolute/100%
backward compatibility is a guaranteed recipe for project failure.
>As long as we're considering things that have
>been ignored for a while, what is our official
>take on Logback? It's basically a realization
>of what Log4j-1.3 was supposed to be, no? Do we
>really have plans to best it as Log4j-2.0? I'm
>not saying we don't. I'm just asking the
>question. And what are we going to do about
>SLF4J? It's gained significant acceptance and
>we've punted on how we are going to approach it;
>implement it directly, write a wrapper for it
>(actually, this has already been done by the
>SLF4J team), or ignore it altogether. So far,
>we've chosen the latter as the path of least resistance.
Contrary to UGLI, SLF4J API forces messages to be
of type String (not Object). As NLOG4J has shown,
you can get away with it, but it will force users
to recompile. On the other hand, natively
implementing SLF4J will work much better in presence of repo-selectors.
>Jake
>
> >cheers,
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Jacob Kjome <ho...@visi.com>.
At 07:07 PM 4/2/2007, you wrote:
>At some point we can no longer ignore the decision about where 1.3
>should go.
>
>I am beginning to think that we should scale back 1.3 to be less of
>the planned revolution and more of a substantial-update-but-
>completely-backward compatible (to a point).
>
I think it's been said before that 1.3 may be more of a dead end than
anything else. Some interesting things went into it, but the fact
that it became so incompatible with Log4j-1.2.xx is a real
problem. Is it worth a release or do we just leave it as-is, forever
alpha, and move on to 2.0?
>We can then step back and think way beyond 1.3 and come up with a new
>vision for what we think is important in enterprise logging.
>
>Firstly, what do people think of this idea?
>
As long as we're considering things that have been ignored for a
while, what is our official take on Logback? It's basically a
realization of what Log4j-1.3 was supposed to be, no? Do we really
have plans to best it as Log4j-2.0? I'm not saying we don't. I'm
just asking the question. And what are we going to do about
SLF4J? It's gained significant acceptance and we've punted on how we
are going to approach it; implement it directly, write a wrapper for
it (actually, this has already been done by the SLF4J team), or
ignore it altogether. So far, we've chosen the latter as the path of
least resistance.
>Secondly, what do people think is left to do before preparing for a
>fully supported 1.3 release ?
>
Do we want to "fully support" 1.3 or just move on? Log4j-1.3 is much
larger than 1.2 because of, among other things, Joran. Joran in 1.3
was Ceki's brainchild and continued development of it has long since
moved to Logback. I'd be more comfortable letting Logback developers
maintain the official version and use it instead of maintaining it
ourselves. I can't recall where I read it, but I believe it was
stated that Joran could be used in other projects, separate from
Logback. Of course, then why not just use Logback? Unless people
are truly prepared to put in the time to figure out what the future
of Log4j should be (and implement it), I'm afraid that Log4j-1.2.xx
is the end of the line, though I'm completely open to being proved wrong.
>Third, who in the dev community (not just committers) is prepared to
>provide some effort in this regard.
>
That's the perennial problem, isn't it?
Jake
>cheers,
>
>Paul
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:51 AM 4/4/2007, Jacob Kjome wrote:
>Yes, I've found the "drop log4j for logback"
>stuff from Ceki a bit disheartening. Well,
>actually I found the whole sudden split from
>Log4j after a vote that didn't go his way a bit
>disheartening. I think the vote went the
>correct way, but I wish we could have avoided the fallout.
For me, starting a new project was a lot worse
than just "disheartening". The SLF4J vote was
just the straw that broke the camel's back. After
putting many many hours of work into log4j, it
became increasingly painful to waste time in
arguments, where opinions got asserted by the one
writing the longest email. Not fun.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Jacob Kjome <ho...@visi.com>.
At 12:51 PM 4/3/2007, you wrote:
>
>On Apr 2, 2007, at 7:07 PM, Paul Smith wrote:
>
>log4j 1.3 in my opinion is stuck in a hopeless position. It is too
>incompatible with log4j 1.2.x to ever be recommended as a drop-in
>replacement for log4j 1.2 in a production environment. However, if
>you changed log4j 1.3 to be drop-in compatible with log4j 1.2, then
>you would break any apps that had depended on its 1.3-ness.
Well said. Plus, I think supporting stuff like Joran and other new
stuff that was never given full attention, because active development
stopped abruptly, is risky. A release is expected to be
supported. People expect non-alpha/beta code to work properly. I'm
not sure we can promise that it will work properly? If we can't
support it, we can't release it.
>
>>
>> Secondly, what do people think is left to do before preparing for
>> a fully supported 1.3 release ?
>>
>
>There are still API incompatibilities (http://people.apache.org/
>~carnold/compatibility.html), particularly any user extensions of
>DOMConfigurator (bug 39024) would not work with log4j 1.3.
>LoggingEvent is not serialization compatible (bug 35159).
>LoggingEvent.sequenceNumber can't achieve what it thought it could
>achieve and should be removed (bug 36555, maybe others). The Gump
>runs have been failing for over a year on the scheduler code behind
>the reworked configureAndWatch methods. Mark Womack threw a quite a
>bit of time on that and could not get it diagnosed. And if you
>fixed all that, you would still break apps that didn't explicitly
>call activateOptions(), it would not address the fundamental
>concurrency problems and would still target early JDK's.
>
Again, how can we promise it will work when we know of stuff like this?
>
>On Apr 3, 2007, at 12:10 AM, Jacob Kjome wrote:
>>
>> I think it's been said before that 1.3 may be more of a dead end
>> than anything else. Some interesting things went into it, but the
>> fact that it became so incompatible with Log4j-1.2.xx is a real
>> problem. Is it worth a release or do we just leave it as-is,
>> forever alpha, and move on to 2.0?
>
>I think forever alpha and move on to 2.0.
I think this might have to be the way. Those using Log4j-1.3 for its
"1.3ness" can continue to use it, albeit in alpha state, and if
someone from the Log4j team wants to make further alpha releases,
that's just fine. But I think it's probably going to have to be left
at that; forever alpha.
>
>>
>> >We can then step back and think way beyond 1.3 and come up with a new
>> >vision for what we think is important in enterprise logging.
>> >
>> >Firstly, what do people think of this idea?
>> >
>>
>> As long as we're considering things that have been ignored for a
>> while, what is our official take on Logback? It's basically a
>> realization of what Log4j-1.3 was supposed to be, no?
>
>I've been hesitant to deeply examine logback as its code is LGPL'd
>and would want to avoid leakage of logback code into log4j.
Good point. I hadn't thought of that.
> We have
>a bit of a marketing disadvantage here as Ceki has been very vocal on
>the mailing lists encouraging people to migrate to logback and saying
>that log4j development is dead (I'd agree that it hasn't been healthy
>recently, but we've never decided that it is dead). I'm also a bit
>of a lightning rod for Ceki and think any evaluation of logback would
>be better coming from someone else.
>
Yes, I've found the "drop log4j for logback" stuff from Ceki a bit
disheartening. Well, actually I found the whole sudden split from
Log4j after a vote that didn't go his way a bit disheartening. I
think the vote went the correct way, but I wish we could have avoided
the fallout.
>> Do we really have plans to best it as Log4j-2.0? I'm not saying we
>> don't. I'm just asking the question.
>
>logback is always going to be a better logback than log4j 2.0 and
>likely a better log4j 1.3 than log4j 2.0. However, I think that the
>design goals and approaches envisioned for log4j 2.0 will result in
>something valuable to the community.
>
Well put.
>> And what are we going to do about SLF4J? It's gained significant
>> acceptance and we've punted on how we are going to approach it;
>> implement it directly, write a wrapper for it (actually, this has
>> already been done by the SLF4J team), or ignore it altogether. So
>> far, we've chosen the latter as the path of least resistance.
>>
>
> From a packaging and maintenance perspective, it has always been
>preferable that SLF4J be a wrapper over log4j. There were never any
>benchmarks provided to quantify the supposed performance benefit of a
>direct implementation. If I remember correctly, supporting SLF4J
>directly introduced a breaking API change when code was recompiled.
>I think the current state is the best for the community. log4j 1.2
>users who want to use SLF4J can do so without forcing them to update
>their log4j 1.2 version and log4j does not have a dependency on SLF4J.
>
...And we don't have to maintain the SLF4J stuff. The only problem
is that repository selectors won't work when using SLF4J wrappers,
but will work using a direct implementation, such as Logback. See...
http://marc.info/?l=slf4j-user&m=117433071915577&w=2
>
>> >Secondly, what do people think is left to do before preparing for a
>> >fully supported 1.3 release ?
>> >
>>
>> Do we want to "fully support" 1.3 or just move on? Log4j-1.3 is
>> much larger than 1.2 because of, among other things, Joran. Joran
>> in 1.3 was Ceki's brainchild and continued development of it has
>> long since moved to Logback. I'd be more comfortable letting
>> Logback developers maintain the official version and use it instead
>> of maintaining it ourselves. I can't recall where I read it, but I
>> believe it was stated that Joran could be used in other projects,
>> separate from Logback. Of course, then why not just use Logback?
>> Unless people are truly prepared to put in the time to figure out
>> what the future of Log4j should be (and implement it), I'm afraid
>> that Log4j-1.2.xx is the end of the line, though I'm completely
>> open to being proved wrong.
>
>Joran is not the only configuration processor in existence, there are
>likely several in ASF alone (http://ws.apache.org/synapse/
>Synapse_Configuration_Language.html for example). I'd see log4j 2.0
>primarily configured by JMX and expose a configuration API that could
>be driven by a log4j 1.2 compatible property and dom configurators
>and something like the strictxml configurator.
>
If 1.3 is to be released, I think it should be without Joran. Either
enhance DOMConfigurator or use an alternative. Maintaining an early
cut of Joran is not a good idea. Of course, no need to bother if 1.3
stays alpha. 2.0 most certainly shouldn't use Joran. Any chosen
configuration mechanism should keep bloat to a minimum and, maybe, be
optional. Log4j.jar is too big as it is.
I'd forgotten about strictxml. A quick Google search brought up...
http://marc.info/?l=apache-logging-general&m=113981617314339&w=2
http://svn.apache.org/repos/asf/logging/sandbox/strictxml
Interesting stuff!
>
>
>On Apr 3, 2007, at 2:09 AM, Paul Smith wrote:
>>>
>>> I think it's been said before that 1.3 may be more of a dead end
>>> than anything else. Some interesting things went into it, but the
>>> fact that it became so incompatible with Log4j-1.2.xx is a real
>>> problem. Is it worth a release or do we just leave it as-is,
>>> forever alpha, and move on to 2.0?
>>>
>>
>> From a Chainsaw point of view a lot of work on creating good
>> Appender->Receiver stuff was done, and as I setup a decent
>> environment for our QA and Ops team to use Chainsaw through a
>> firewall (port forwarding) while our app is using log4j 1.2.14, I'm
>> beginning to see a dilemma. serialized LoggingEvents from 1.2 just
>> don't contain lots of info coming out the other end. I then asked
>> myself the question "Should we upgrade our app to use log4j 1.3",
>> and I honestly couldn't say what the quality was, hence the line-in-
>> the-sand email.
>
>I'd love to hear (in a different thread) what would need to be back-
>ported to log4j 1.2.x to move Chainsaw back over it.
>
A good goal indeed.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:51 PM 4/3/2007, Curt Arnold wrote:
>There are still API incompatibilities
>(http://people.apache.org/
>~carnold/compatibility.html), particularly any user extensions of
>DOMConfigurator (bug 39024) would not work with log4j 1.3.
>LoggingEvent is not serialization compatible (bug 35159).
>LoggingEvent.sequenceNumber can't achieve what it thought it could
>achieve and should be removed (bug 36555, maybe others). The Gump
>runs have been failing for over a year on the scheduler code behind
>the reworked configureAndWatch methods. Mark Womack threw a quite a
>bit of time on that and could not get it diagnosed. And if you
>fixed all that, you would still break apps that didn't explicitly
>call activateOptions(), it would not address the fundamental
>concurrency problems and would still target early JDK's.
The problems you mention are really minor.
[snip]
>I've been hesitant to deeply examine logback as its code is LGPL'd
>and would want to avoid leakage of logback code into log4j. We have
>a bit of a marketing disadvantage here as Ceki has been very vocal on
>the mailing lists encouraging people to migrate to logback and saying
>that log4j development is dead (I'd agree that it hasn't been healthy
>recently, but we've never decided that it is dead). I'm also a bit
>of a lightning rod for Ceki and think any evaluation of logback would
>be better coming from someone else.
It's quite ironic that you should feel at "a
marketing disadvantage". While it is true that I
mention logback as a successor to log4j, I do so
occasionally. Moreover, I've extremely careful to
refer to log4j as "not actively developed", a
characterization, which as other log4j developers, you seem to agree with.
>>Do we really have plans to best it as Log4j-2.0? I'm not saying we
>>don't. I'm just asking the question.
>
>logback is always going to be a better logback than log4j 2.0 and
>likely a better log4j 1.3 than log4j 2.0. However, I think that the
>design goals and approaches envisioned for log4j 2.0 will result in
>something valuable to the community.
>
>>And what are we going to do about SLF4J? It's gained significant
>>acceptance and we've punted on how we are going to approach it;
>>implement it directly, write a wrapper for it (actually, this has
>>already been done by the SLF4J team), or ignore it altogether. So
>>far, we've chosen the latter as the path of least resistance.
>
> From a packaging and maintenance perspective, it has always been
>preferable that SLF4J be a wrapper over log4j. There were never any
>benchmarks provided to quantify the supposed performance benefit of a
>direct implementation. If I remember correctly, supporting SLF4J
>directly introduced a breaking API change when code was recompiled.
>I think the current state is the best for the community. log4j 1.2
>users who want to use SLF4J can do so without forcing them to update
>their log4j 1.2 version and log4j does not have a dependency on SLF4J.
The original version of UGLI and than SLF4J was
designed to be compatible with log4j.
[snip]
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Paul Smith <ps...@aconex.com>.
>
> log4j 1.3 in my opinion is stuck in a hopeless position. It is too
> incompatible with log4j 1.2.x to ever be recommended as a drop-in
> replacement for log4j 1.2 in a production environment. However, if
> you changed log4j 1.3 to be drop-in compatible with log4j 1.2, then
> you would break any apps that had depended on its 1.3-ness.
>
Well, I don't think we are ever required to support anything built
upon an 'alpha' version of log4j1.3. Anyone who has decided to base
some changes on an alpha quality release knew the risks. There was
never a guarantee 1.3.x wasn't a moving target. Having said that,
I'm not completely concerned about leaving 1.3 as a dead end and
moving one. I'd just like to get the dev community fired up and
moving in _some_ direction.. :)
>
> Elias Ross appeared to be motivated to push log4j 1.3 forward and
> while I did not think it was where I thought my time was best spent
> (and I've spent a huge amount of time killing off
> incompatibilities), I was willing to let him prove me wrong and the
> PMC granted him commit privileges. Unfortunately, he did a bug fix
> spurt and then disappeared.
>
I honestly don't know what happened there. It was odd, no question.
>>
>> From a Chainsaw point of view a lot of work on creating good
>> Appender->Receiver stuff was done, and as I setup a decent
>> environment for our QA and Ops team to use Chainsaw through a
>> firewall (port forwarding) while our app is using log4j 1.2.14,
>> I'm beginning to see a dilemma. serialized LoggingEvents from 1.2
>> just don't contain lots of info coming out the other end. I then
>> asked myself the question "Should we upgrade our app to use log4j
>> 1.3", and I honestly couldn't say what the quality was, hence the
>> line-in-the-sand email.
>
> I'd love to hear (in a different thread) what would need to be back-
> ported to log4j 1.2.x to move Chainsaw back over it.
>
>
Mostly LoggingEvent stuff, I'll do a diff of 1.2-> 1.3 for further
discussions in another thread. It's mainly MDC that is missing I
think. Scott can you remember any context here? (The diff will tell
I think)
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3 - A Line in the Sand
Posted by Curt Arnold <ca...@apache.org>.
On Apr 2, 2007, at 7:07 PM, Paul Smith wrote:
> At some point we can no longer ignore the decision about where 1.3
> should go.
>
> I am beginning to think that we should scale back 1.3 to be less of
> the planned revolution and more of a substantial-update-but-
> completely-backward compatible (to a point).
>
> We can then step back and think way beyond 1.3 and come up with a
> new vision for what we think is important in enterprise logging.
>
> Firstly, what do people think of this idea?
log4j 1.3 in my opinion is stuck in a hopeless position. It is too
incompatible with log4j 1.2.x to ever be recommended as a drop-in
replacement for log4j 1.2 in a production environment. However, if
you changed log4j 1.3 to be drop-in compatible with log4j 1.2, then
you would break any apps that had depended on its 1.3-ness.
>
> Secondly, what do people think is left to do before preparing for
> a fully supported 1.3 release ?
>
There are still API incompatibilities (http://people.apache.org/
~carnold/compatibility.html), particularly any user extensions of
DOMConfigurator (bug 39024) would not work with log4j 1.3.
LoggingEvent is not serialization compatible (bug 35159).
LoggingEvent.sequenceNumber can't achieve what it thought it could
achieve and should be removed (bug 36555, maybe others). The Gump
runs have been failing for over a year on the scheduler code behind
the reworked configureAndWatch methods. Mark Womack threw a quite a
bit of time on that and could not get it diagnosed. And if you
fixed all that, you would still break apps that didn't explicitly
call activateOptions(), it would not address the fundamental
concurrency problems and would still target early JDK's.
> Third, who in the dev community (not just committers) is prepared
> to provide some effort in this regard.
>
Elias Ross appeared to be motivated to push log4j 1.3 forward and
while I did not think it was where I thought my time was best spent
(and I've spent a huge amount of time killing off incompatibilities),
I was willing to let him prove me wrong and the PMC granted him
commit privileges. Unfortunately, he did a bug fix spurt and then
disappeared.
On Apr 3, 2007, at 12:10 AM, Jacob Kjome wrote:
>
> I think it's been said before that 1.3 may be more of a dead end
> than anything else. Some interesting things went into it, but the
> fact that it became so incompatible with Log4j-1.2.xx is a real
> problem. Is it worth a release or do we just leave it as-is,
> forever alpha, and move on to 2.0?
I think forever alpha and move on to 2.0.
>
> >We can then step back and think way beyond 1.3 and come up with a new
> >vision for what we think is important in enterprise logging.
> >
> >Firstly, what do people think of this idea?
> >
>
> As long as we're considering things that have been ignored for a
> while, what is our official take on Logback? It's basically a
> realization of what Log4j-1.3 was supposed to be, no?
I've been hesitant to deeply examine logback as its code is LGPL'd
and would want to avoid leakage of logback code into log4j. We have
a bit of a marketing disadvantage here as Ceki has been very vocal on
the mailing lists encouraging people to migrate to logback and saying
that log4j development is dead (I'd agree that it hasn't been healthy
recently, but we've never decided that it is dead). I'm also a bit
of a lightning rod for Ceki and think any evaluation of logback would
be better coming from someone else.
> Do we really have plans to best it as Log4j-2.0? I'm not saying we
> don't. I'm just asking the question.
logback is always going to be a better logback than log4j 2.0 and
likely a better log4j 1.3 than log4j 2.0. However, I think that the
design goals and approaches envisioned for log4j 2.0 will result in
something valuable to the community.
> And what are we going to do about SLF4J? It's gained significant
> acceptance and we've punted on how we are going to approach it;
> implement it directly, write a wrapper for it (actually, this has
> already been done by the SLF4J team), or ignore it altogether. So
> far, we've chosen the latter as the path of least resistance.
>
From a packaging and maintenance perspective, it has always been
preferable that SLF4J be a wrapper over log4j. There were never any
benchmarks provided to quantify the supposed performance benefit of a
direct implementation. If I remember correctly, supporting SLF4J
directly introduced a breaking API change when code was recompiled.
I think the current state is the best for the community. log4j 1.2
users who want to use SLF4J can do so without forcing them to update
their log4j 1.2 version and log4j does not have a dependency on SLF4J.
> >Secondly, what do people think is left to do before preparing for a
> >fully supported 1.3 release ?
> >
>
> Do we want to "fully support" 1.3 or just move on? Log4j-1.3 is
> much larger than 1.2 because of, among other things, Joran. Joran
> in 1.3 was Ceki's brainchild and continued development of it has
> long since moved to Logback. I'd be more comfortable letting
> Logback developers maintain the official version and use it instead
> of maintaining it ourselves. I can't recall where I read it, but I
> believe it was stated that Joran could be used in other projects,
> separate from Logback. Of course, then why not just use Logback?
> Unless people are truly prepared to put in the time to figure out
> what the future of Log4j should be (and implement it), I'm afraid
> that Log4j-1.2.xx is the end of the line, though I'm completely
> open to being proved wrong.
Joran is not the only configuration processor in existence, there are
likely several in ASF alone (http://ws.apache.org/synapse/
Synapse_Configuration_Language.html for example). I'd see log4j 2.0
primarily configured by JMX and expose a configuration API that could
be driven by a log4j 1.2 compatible property and dom configurators
and something like the strictxml configurator.
On Apr 3, 2007, at 2:09 AM, Paul Smith wrote:
>>
>> I think it's been said before that 1.3 may be more of a dead end
>> than anything else. Some interesting things went into it, but the
>> fact that it became so incompatible with Log4j-1.2.xx is a real
>> problem. Is it worth a release or do we just leave it as-is,
>> forever alpha, and move on to 2.0?
>>
>
> From a Chainsaw point of view a lot of work on creating good
> Appender->Receiver stuff was done, and as I setup a decent
> environment for our QA and Ops team to use Chainsaw through a
> firewall (port forwarding) while our app is using log4j 1.2.14, I'm
> beginning to see a dilemma. serialized LoggingEvents from 1.2 just
> don't contain lots of info coming out the other end. I then asked
> myself the question "Should we upgrade our app to use log4j 1.3",
> and I honestly couldn't say what the quality was, hence the line-in-
> the-sand email.
I'd love to hear (in a different thread) what would need to be back-
ported to log4j 1.2.x to move Chainsaw back over it.
>>
>> As long as we're considering things that have been ignored for a
>> while, what is our official take on Logback? It's basically a
>> realization of what Log4j-1.3 was supposed to be, no? Do we
>> really have plans to best it as Log4j-2.0? I'm not saying we
>> don't. I'm just asking the question. And what are we going to do
>> about SLF4J? It's gained significant acceptance and we've punted
>> on how we are going to approach it; implement it directly, write a
>> wrapper for it (actually, this has already been done by the SLF4J
>> team), or ignore it altogether. So far, we've chosen the latter
>> as the path of least resistance.
>>
>
> My somewhat superficial scan over logback shows a lot of promise
> from an end user point of view. I would certainly be interested in
> exploring that as an option. This is where licenses, politics and
> marketing all come to a head which are never fun.
>
> * Is bringing logback into Apache something the logback community
> would even remotely consider? Ceki, I know you're watching, do you
> think that it might obtain wider exposure by coming under the
> logging.apache.org banner? Is that something that you've ever
> thought of? I totally respect the community logback has already
> established.
>
> * Would the Apache dev community even consider looking at that sort
> of proposal?
I think offering logback with a double license (LGPL and ASL) would
be beneficial. Ceki spun off the SLF4J effort since he thought he
would be more effective outside of the ASF and the overhead of
community development and governance. I haven't seen any indication
that that has changed. Also, it would have to come through the
incubator and that isn't fun. I believe the ASF board is determined
that code that isn't developed in accordance with open, public
discussion and conflict resolution should not be in the ASF.
>
> Apache log4j has a decent 'brand' behind it, and many people are
> familiar with it and support it, but we've become stagnant, and
> perhaps people are moving on. The logback project, if 'absorbed'
> as a new log4j version could well gain bigger traction quickly
> purely because of that brand and revitalize logging.apache.org as a
> broader community (I'm thinking non-java languages here). What
> we want is a healthy dev community, and right now I'm not sure we
> (log4j) have one. Curt's been the only one doing anything recently.
I'm definitely supportive of efforts with other languages (but it
would also need to come with motivated developers). There is an open
bug request on logging for Javascript (bug 36961). I don't think
that the health of log4j development or bringing logback into LS
would make or break a log4js or a log4 ruby et al. If someone is
interested in building a community for an effort in a particular
language, start a thread on general@logging and we can look at
starting a sandbox project.
> I'd be keen to consider starting Chainsaw v3 from scratch along
> side any post-log4j1.3-type operation and build in exceptional
> support for enterprise log management, but I'm only one person, and
> I know many of us are incredibly busy, but we were so active there
> for a while I think of the potential of what we could achieve! :)
> From a Java point of view I think many of the Java 1.4+ network
> library, and java.util.concurrent stuff could be well used in a new
> logging package.
>
>>
>> Do we want to "fully support" 1.3 or just move on? Log4j-1.3 is
>> much larger than 1.2 because of, among other things, Joran. Joran
>> in 1.3 was Ceki's brainchild and continued development of it has
>> long since moved to Logback. I'd be more comfortable letting
>> Logback developers maintain the official version and use it
>> instead of maintaining it ourselves. I can't recall where I read
>> it, but I believe it was stated that Joran could be used in other
>> projects, separate from Logback. Of course, then why not just use
>> Logback? Unless people are truly prepared to put in the time to
>> figure out what the future of Log4j should be (and implement it),
>> I'm afraid that Log4j-1.2.xx is the end of the line, though I'm
>> completely open to being proved wrong.
>>
> What you say certainly seems possible. If we're not careful, the
> log4j project could dwindle into nothing (not that that's a
> problem, just sad).
I expressed some of the same sentiments in the last board report.
Unfortunately, the minutes haven't been published yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org