You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2005/04/29 20:13:22 UTC
Release of log4j version 1.2.10
Log4j developers are proud to announce the availability of log4j
version 1.2.10. This version adds native support for SLF4J, along with
a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
intended to serve as a simple facade for various logging APIs allowing
to the end-user to plug in the desired implementation at deployment
time. For more details about SLF4J, see
http://www.slf4j.org
You can download log4j version 1.2.10 at
http://logging.apache.org/site/binindex.html
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by Curt Arnold <ca...@apache.org>.
I have added a mild disclaimer to binary distributions page in the CVS
for logging-site. I also added a link to the cvsweb for
logging-chainsaw. At the moment, the pages served by
logging.apache.org do not show either modification. I'm hoping it is a
replication lag.
Given that there was no vote on log4j 1.2.10 and significant issues
worthy of discussion, I felt that is was essential that there be some
disclaimer so that unsuspecting visitors to the log4j web site would
not download a supposed production release that does not have the
endorsement of the PMC. Text is:
Disclaimer: This release was posted without a required vote and may be
withdrawn.
In my previous message, I had attempted to describe one mechanism that
an SLF4J facade over log4j could offer comparable performance to a
direct implementation of SLF4J within log4j. There are likely other
approaches that could also work and the one I outlined may not be the
best. The intent was not to start a discussion on how write a
performant facade, but that there was the potential for a performant
facade so committing to a direct implementation in a production release
was premature.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by Ceki Gülcü <ce...@qos.ch>.
I guess you involuntarily missed the HISTORY.txt file.
http://cvs.apache.org/viewcvs.cgi/jakarta-log4j/docs/HISTORY.txt?rev=1.27.2.1&view=markup
http://issues.apache.org/bugzilla/show_bug.cgi?id=34491
At 08:23 4/30/2005, Curt Arnold wrote:
>On Apr 29, 2005, at 1:13 PM, Ceki Gülcü wrote:
>
>>
>>Log4j developers are proud to announce the availability of log4j
>>version 1.2.10. This version adds native support for SLF4J, along with
>>a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
>>intended to serve as a simple facade for various logging APIs allowing
>>to the end-user to plug in the desired implementation at deployment
>>time. For more details about SLF4J, see
>
>
>I reviewed the changes between v1_2_9 and the v1_2-branch (I didn't find a
>label for v1_2_10) using:
>
>cvs -z3 diff -r v1_2_9 -r v1_2-branch
>
>
>And I couldn't find the minor bug fix unless it was in the
>documentation. The following files were changed:
>
>RCS file: /home/cvs/logging-log4j/build.xml,v
>RCS file: /home/cvs/logging-log4j/docs/Attic/FAQ.html,v
>RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Category.java,v
>RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Logger.java,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/Attic/contactUs.xml,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/contributors.xml,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/documentation.xml,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/download.xml,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/earlier.xml,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/history.xml,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/index.xml,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/plan.xml,v
>RCS file: /home/cvs/logging-log4j/src/xdocs/stylesheets/project.xml,v
>
>
>The significant changes appear to be (sections omitted):
>
>Index: src/java/org/apache/log4j/Category.java
>===================================================================
>RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Category.java,v
>retrieving revision 1.68.2.5
>retrieving revision 1.68.2.6
>diff -r1.68.2.5 -r1.68.2.6
>33a34
> > import org.slf4j.impl.MessageFormatter;
>251a253,306
>
> > public void debug(Object messagePattern, Object arg) {
>
> > public void debug(String messagePattern, Object arg1, Object arg2) {
>
> > public void error(Object messagePattern, Object arg) {
>
> > public void error(String messagePattern, Object arg1, Object arg2) {
>
> > public void info(Object messagePattern, Object arg) {
>
> > public void info(String messagePattern, Object arg1, Object arg2) {
>
>755a921,947
>
> > public boolean isWarnEnabled() {
>
> > public boolean isErrorEnabled() {
>
>1001a1194,1247
>
> > public void warn(Object messagePattern, Object arg) {
>
> > public void warn(String messagePattern, Object arg1, Object arg2) {
>
>Index: src/java/org/apache/log4j/Logger.java
>===================================================================
>RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Logger.java,v
>retrieving revision 1.16.2.1
>retrieving revision 1.16.2.2
>diff -r1.16.2.1 -r1.16.2.2
>10a11
> > import org.slf4j.ULogger;
>20c21
>< public class Logger extends Category {
>---
> > public class Logger extends Category implements ULogger {
>
>
>
>
>I reviewed the slf4j.org web site and there is a release labeled
>slf4j-1.0-beta1 and user and dev mailing lists with no logged
>messages. My understanding of the motivation to spin UGLI out of ASF was
>so that interested parties would have an neutral site where to resolve all
>the thorny issues that have been encountered with previous approaches at a
>common logging API. However by incorporating this particular version of
>SLF4J into a production release of log4j, that greatly limits the freedom
>of the SLF4J community to make changes or additions to the interfaces (or
>conversely places a production version of log4j at their whims). For
>example, if a new method is added to ULogger, calling code will receive a
>MethodNotFound exception when running against log4j 1.2.10.
>
>I understand the desire to eliminate the facade-tax by making log4j
>directly implement ULogger and maybe there will be enough consensus around
>SLF4J by the time log4j 1.3 is production ready that there will be
>acceptable. However as SLF4J as an entity is only weeks old and appears
>to have zero-community at this point, it seems totally inappropriate to
>add it as a dependency for the 10th release of log4j 1.2.
>
>Even if SLF4J becomes generally accepted, my preference would for it still
>to be a facade over log4j. But there may be ways to almost eliminate the
>facade-tax. If the message satisfies the threshold of the logger or
>hierarchy and is likely to be logged, the additional function call from
>the facade to the implementation should not be significant. The crucial
>issue is to make the evaluation of that initial screen to be as fast as
>possible. If the facade has enough information to make that determination
>without delegating to the underlying implementation, there performance
>between an directly implemented SLF4J and a facade should be very hard to
>detect. To do that in an environment where the configuration may be
>changing, that would require mechanisms for the facade to register its
>interest in configuration changes however that could be done to support
>slf4j without adding any slf4j dependencies to log4j. If you want to
>support that approach, you may want to add another versions of
>org.slf4j.LoggerFactory.getLogger that takes a boolean parameter
>indicating whether the logger should monitor threshold changes. If false,
>then the implementation would be free to get the level of the logger on
>the first call and cache that value, and if the parameter was true the
>implementation could monitor the level on implementations that support it
>(log4j 1.3) or always delegate to the underlying implementation.
>
>At this point, I think the best thing to do is pull 1.2.10 and pretend it
>never existed. As far as I can tell there are no bug fixes in 1.2.9
>except possibly in the documentation and I don't think doc changes would
>be sufficient to justify another release.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by Curt Arnold <ca...@apache.org>.
On Apr 29, 2005, at 1:13 PM, Ceki Gülcü wrote:
>
> Log4j developers are proud to announce the availability of log4j
> version 1.2.10. This version adds native support for SLF4J, along with
> a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
> intended to serve as a simple facade for various logging APIs allowing
> to the end-user to plug in the desired implementation at deployment
> time. For more details about SLF4J, see
I reviewed the changes between v1_2_9 and the v1_2-branch (I didn't
find a label for v1_2_10) using:
cvs -z3 diff -r v1_2_9 -r v1_2-branch
And I couldn't find the minor bug fix unless it was in the
documentation. The following files were changed:
RCS file: /home/cvs/logging-log4j/build.xml,v
RCS file: /home/cvs/logging-log4j/docs/Attic/FAQ.html,v
RCS file:
/home/cvs/logging-log4j/src/java/org/apache/log4j/Category.java,v
RCS file:
/home/cvs/logging-log4j/src/java/org/apache/log4j/Logger.java,v
RCS file: /home/cvs/logging-log4j/src/xdocs/Attic/contactUs.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/contributors.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/documentation.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/download.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/earlier.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/history.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/index.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/plan.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/stylesheets/project.xml,v
The significant changes appear to be (sections omitted):
Index: src/java/org/apache/log4j/Category.java
===================================================================
RCS file:
/home/cvs/logging-log4j/src/java/org/apache/log4j/Category.java,v
retrieving revision 1.68.2.5
retrieving revision 1.68.2.6
diff -r1.68.2.5 -r1.68.2.6
33a34
> import org.slf4j.impl.MessageFormatter;
251a253,306
> public void debug(Object messagePattern, Object arg) {
> public void debug(String messagePattern, Object arg1, Object arg2) {
> public void error(Object messagePattern, Object arg) {
> public void error(String messagePattern, Object arg1, Object arg2) {
> public void info(Object messagePattern, Object arg) {
> public void info(String messagePattern, Object arg1, Object arg2) {
755a921,947
> public boolean isWarnEnabled() {
> public boolean isErrorEnabled() {
1001a1194,1247
> public void warn(Object messagePattern, Object arg) {
> public void warn(String messagePattern, Object arg1, Object arg2) {
Index: src/java/org/apache/log4j/Logger.java
===================================================================
RCS file:
/home/cvs/logging-log4j/src/java/org/apache/log4j/Logger.java,v
retrieving revision 1.16.2.1
retrieving revision 1.16.2.2
diff -r1.16.2.1 -r1.16.2.2
10a11
> import org.slf4j.ULogger;
20c21
< public class Logger extends Category {
---
> public class Logger extends Category implements ULogger {
I reviewed the slf4j.org web site and there is a release labeled
slf4j-1.0-beta1 and user and dev mailing lists with no logged messages.
My understanding of the motivation to spin UGLI out of ASF was so that
interested parties would have an neutral site where to resolve all the
thorny issues that have been encountered with previous approaches at a
common logging API. However by incorporating this particular version
of SLF4J into a production release of log4j, that greatly limits the
freedom of the SLF4J community to make changes or additions to the
interfaces (or conversely places a production version of log4j at their
whims). For example, if a new method is added to ULogger, calling code
will receive a MethodNotFound exception when running against log4j
1.2.10.
I understand the desire to eliminate the facade-tax by making log4j
directly implement ULogger and maybe there will be enough consensus
around SLF4J by the time log4j 1.3 is production ready that there will
be acceptable. However as SLF4J as an entity is only weeks old and
appears to have zero-community at this point, it seems totally
inappropriate to add it as a dependency for the 10th release of log4j
1.2.
Even if SLF4J becomes generally accepted, my preference would for it
still to be a facade over log4j. But there may be ways to almost
eliminate the facade-tax. If the message satisfies the threshold of
the logger or hierarchy and is likely to be logged, the additional
function call from the facade to the implementation should not be
significant. The crucial issue is to make the evaluation of that
initial screen to be as fast as possible. If the facade has enough
information to make that determination without delegating to the
underlying implementation, there performance between an directly
implemented SLF4J and a facade should be very hard to detect. To do
that in an environment where the configuration may be changing, that
would require mechanisms for the facade to register its interest in
configuration changes however that could be done to support slf4j
without adding any slf4j dependencies to log4j. If you want to support
that approach, you may want to add another versions of
org.slf4j.LoggerFactory.getLogger that takes a boolean parameter
indicating whether the logger should monitor threshold changes. If
false, then the implementation would be free to get the level of the
logger on the first call and cache that value, and if the parameter was
true the implementation could monitor the level on implementations that
support it (log4j 1.3) or always delegate to the underlying
implementation.
At this point, I think the best thing to do is pull 1.2.10 and pretend
it never existed. As far as I can tell there are no bug fixes in 1.2.9
except possibly in the documentation and I don't think doc changes
would be sufficient to justify another release.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
FYI: Release of log4j version 1.2.10
Posted by Curt Arnold <ca...@apache.org>.
Please be aware there is a discussion on log4j-dev on this release.
On Apr 29, 2005, at 1:13 PM, Ceki Gülcü wrote:
>
> Log4j developers are proud to announce the availability of log4j
> version 1.2.10. This version adds native support for SLF4J, along with
> a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
> intended to serve as a simple facade for various logging APIs allowing
> to the end-user to plug in the desired implementation at deployment
> time. For more details about SLF4J, see
>
> http://www.slf4j.org
>
> You can download log4j version 1.2.10 at
>
> http://logging.apache.org/site/binindex.html
>
>
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by Ceki Gülcü <ce...@qos.ch>.
I am aware of the problem. Thanks Jim.
At 21:54 4/29/2005, you wrote:
>Hi Ceki,
>
>Not having much luck on the link at
>http://logging.apache.org/site/binindex.html which is directed at
>http://logging.apache.org/site/[preferred]logging/log4j/1.2.10/logging-log4j-1.2.10.zip
>
>However, I was able to download 1.2.10 by heading to this URL
>http://www.apache.org/dist/logging/log4j/1.2.10/.
>
>I really appreciate all the work you all do for this project.
>
>Thanks,
>
>Jim
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by Jim Rice <ji...@gmail.com>.
Hi Ceki,
Not having much luck on the link at
http://logging.apache.org/site/binindex.html which is directed at
http://logging.apache.org/site/[preferred]logging/log4j/1.2.10/logging-log4j-1.2.10.zip
However, I was able to download 1.2.10 by heading to this URL
http://www.apache.org/dist/logging/log4j/1.2.10/.
I really appreciate all the work you all do for this project.
Thanks,
Jim
On 4/29/05, Ceki Gülcü <ce...@qos.ch> wrote:
>
> Log4j developers are proud to announce the availability of log4j
> version 1.2.10. This version adds native support for SLF4J, along with
> a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
> intended to serve as a simple facade for various logging APIs allowing
> to the end-user to plug in the desired implementation at deployment
> time. For more details about SLF4J, see
>
> http://www.slf4j.org
>
> You can download log4j version 1.2.10 at
>
> http://logging.apache.org/site/binindex.html
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by James Stauffer <st...@gmail.com>.
Does SLF4J basically fit the same need as commons-logging?
(With the advantage that SLF4J doesn't have classloading issues)
On 4/29/05, Ceki Gülcü <ce...@qos.ch> wrote:
>
> Log4j developers are proud to announce the availability of log4j
> version 1.2.10. This version adds native support for SLF4J, along with
> a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
> intended to serve as a simple facade for various logging APIs allowing
> to the end-user to plug in the desired implementation at deployment
> time. For more details about SLF4J, see
>
> http://www.slf4j.org
>
> You can download log4j version 1.2.10 at
>
> http://logging.apache.org/site/binindex.html
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
James Stauffer
Are you good? Take the test at http://www.livingwaters.com/good/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by Curt Arnold <ca...@apache.org>.
On Apr 29, 2005, at 4:00 PM, Ceki Gülcü wrote:
>
>
> The idea of migration to SLF4J from UGLI was discussed several weeks
> ago and was received favorably. Moreover, the SLF4J code is not new.
> Actually, SLF4J has been part of log4j HEAD with a different name
> (UGLI) for over 10 months. At present time, SLF4j is also part of CVS
> HEAD.
I followed that discussion, but maybe not closely enough. My
impression (possibly not accurate) was that the UGLI code was being
removed for log4j and that SLF4J was being established under a
non-Apache license. I had no problem with that.
I was not aware that the intention was to make log4j (and particularly
the 1.2 branch) dependent on non-Apache code that is likely effectively
personally copyrighted and completely under Ceki's control. By
removing it from ASF and but then incorporating it by reference into
log4j, it effectively eliminates the control the log4j project is
supposed to have over code in its project.
The implementation of SLF4J for JDK 1.4 logging is able to be down
externally from the JDK 1.4 implementation. I would assume that the
log4j implementation(s) could also be done externally. For anyone
interested in SLF4J, an external implementation of SLF4J for log4j 1.2
would be preferable since it would be able to be used with existing
deployments of early log4j versions. Adding would also seem to violate
the consensus of not adding new features to the log4j 1.2 branch.
>
> SLF4J solves some serious reliability problems hundreds of users
> suffer from daily. When our users can deploy log4j reliably, it is
> fair to say that the log4j project stands to gain from SLF4J.
That may be true. However, SLF4J is just emerging and has no
widespread acceptance. It may or may not be subject to change. I
don't know of any discussion how we would keep log4j in synch with
subsequence versions of SLF4J.
>
> Please note that the 1.2.10 release is 100% compatible with previous
> 1.2 releases. I really was not expecting a controversy surrounding
> this release. Consequently, I may have rushed it a little, hoping for
> your continued support and understanding.
>
However, it introduces a second license in an Apache distribution.
Even if it is compatible, it complicates the analysis of licensing
issues since users have to check that the SDF4J license is actually an
X11 license and feel comfortable with it. It might not be a big deal,
but it should be at least of some concern.
It also implies that SDF4J will be a maintained feature of future log4j
1.2 releases and the log4j 1.3 series at least till it would go through
a release where it was deprecated.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by Paul Smith <ps...@aconex.com>.
>
> Please note that the 1.2.10 release is 100% compatible with previous
> 1.2 releases. I really was not expecting a controversy surrounding
> this release. Consequently, I may have rushed it a little, hoping for
> your continued support and understanding.
>
Forget any controversy or lack thereof, there's supposed to be a process
of an explicit vote and oversight. (we're required to by the board IIUC).
I was certainly not expecting a release.
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Release of log4j version 1.2.10
Posted by Ceki Gülcü <ce...@qos.ch>.
The idea of migration to SLF4J from UGLI was discussed several weeks
ago and was received favorably. Moreover, the SLF4J code is not new.
Actually, SLF4J has been part of log4j HEAD with a different name
(UGLI) for over 10 months. At present time, SLF4j is also part of CVS
HEAD.
SLF4J solves some serious reliability problems hundreds of users
suffer from daily. When our users can deploy log4j reliably, it is
fair to say that the log4j project stands to gain from SLF4J.
Please note that the 1.2.10 release is 100% compatible with previous
1.2 releases. I really was not expecting a controversy surrounding
this release. Consequently, I may have rushed it a little, hoping for
your continued support and understanding.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Release of log4j version 1.2.10
Posted by Curt Arnold <ca...@apache.org>.
I'm very much concerned. Much of the code in log4j 1.2.10 was only in
the CVS a few hours and last night's Gump build failed. It seems
amazing for a maintenance release to be rushed so quickly.
The following things trouble me:
1. Release of 1.2.10 with no vote
2. Preparation of 1.2.10 candidate with no apparent discussion (the
first mention of 1.2.10 is dated yesterday)
3. Incorporating code that is copyright slf4j.org and under non-Apache
license
4. No apparent discussion on incorporating sl4j.org code into the 1.2
branch
All the items (with possible exception of #2) should have been
discussed and voted on.
Since anyone using 1.2.x will think that 1.2.10 is production-ready and
has the full backing of the Logging PMC, I really think it has to be
pulled.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Release of log4j version 1.2.10
Posted by Mark Womack <wo...@adobe.com>.
Yeah, it does require a PMC vote (and an implied sub-project vote before it
goes to the PMC).
http://logging.apache.org/site/bylaws.html
to wit:
Product Release
When a release of one of the sub-project's products is ready, a vote is
required to accept the release as an official release of the Logging
Services project.
This step ensures the overall supervision by the Logging Services PMC over
its sub-projects.
Lazy Majority Active PMC members
I mean, what is the point of having the process if we are not going to
follow it. The release could have waited for the voting process, there was
no burning reason to release it immediately, bypassing the entire thing,
whether you thought it was controversial or not.
I appreciate the work, but this concerns me.
-Mark
> -----Original Message-----
> From: Mark Womack [mailto:womack@adobe.com]
> Sent: Friday, April 29, 2005 11:42 AM
> To: 'Log4J Developers List'
> Subject: RE: Release of log4j version 1.2.10
>
> OK, so I would have voted for the release, but isn't there a process we
> are
> supposed to follow here? Something about the sub-project voting and the
> PMC
> approving, etc. ?
>
> -Mark
>
> > -----Original Message-----
> > From: Ceki Gülcü [mailto:ceki@qos.ch]
> > Sent: Friday, April 29, 2005 11:29 AM
> > To: Log4J Developers List
> > Subject: RE: Release of log4j version 1.2.10
> >
> >
> > Hi Yoav,
> >
> > Given that this release mimics the code that is already on the main
> > branch, and that it is 100% backward compatible with 1.2.9 (no
> > exceptions, buts or ifs), I do not expect any controversy surrounding
> > this release.
> >
> > Congratulations by the way! :-)
> >
> > At 20:19 4/29/2005, Yoav Shapira wrote:
> > >Hi,
> > >It would have been nice to have a vote on this release, no? ;)
> > >
> > >No big deal. Thanks for putting it together so quickly.
> > >
> > >Yoav Shapira
> > >System Design and Management Fellow
> > >MIT Sloan School of Management / School of Engineering
> > >Cambridge, MA USA
> > >yoavsh@sloan.mit.edu / yoavs@computer.org
> >
> > --
> > Ceki Gülcü
> >
> > The complete log4j manual: http://www.qos.ch/log4j/
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Release of log4j version 1.2.10
Posted by Mark Womack <wo...@adobe.com>.
OK, so I would have voted for the release, but isn't there a process we are
supposed to follow here? Something about the sub-project voting and the PMC
approving, etc. ?
-Mark
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: Friday, April 29, 2005 11:29 AM
> To: Log4J Developers List
> Subject: RE: Release of log4j version 1.2.10
>
>
> Hi Yoav,
>
> Given that this release mimics the code that is already on the main
> branch, and that it is 100% backward compatible with 1.2.9 (no
> exceptions, buts or ifs), I do not expect any controversy surrounding
> this release.
>
> Congratulations by the way! :-)
>
> At 20:19 4/29/2005, Yoav Shapira wrote:
> >Hi,
> >It would have been nice to have a vote on this release, no? ;)
> >
> >No big deal. Thanks for putting it together so quickly.
> >
> >Yoav Shapira
> >System Design and Management Fellow
> >MIT Sloan School of Management / School of Engineering
> >Cambridge, MA USA
> >yoavsh@sloan.mit.edu / yoavs@computer.org
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> 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: Release of log4j version 1.2.10
Posted by Ceki Gülcü <ce...@qos.ch>.
Hi Yoav,
Given that this release mimics the code that is already on the main
branch, and that it is 100% backward compatible with 1.2.9 (no
exceptions, buts or ifs), I do not expect any controversy surrounding
this release.
Congratulations by the way! :-)
At 20:19 4/29/2005, Yoav Shapira wrote:
>Hi,
>It would have been nice to have a vote on this release, no? ;)
>
>No big deal. Thanks for putting it together so quickly.
>
>Yoav Shapira
>System Design and Management Fellow
>MIT Sloan School of Management / School of Engineering
>Cambridge, MA USA
>yoavsh@sloan.mit.edu / yoavs@computer.org
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Release of log4j version 1.2.10
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
I suggest you read the rest of the threads (not just the original message
you quoted) before ranting further ;)
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management / School of Engineering
Cambridge, MA USA
yoavsh@sloan.mit.edu / yoavs@computer.org
> -----Original Message-----
> From: Endre Stølsvik [mailto:Endre@Stolsvik.com]
> Sent: Tuesday, May 03, 2005 5:33 AM
> To: Log4J Developers List
> Cc: log4j-user@logging.apache.org
> Subject: Re: Release of log4j version 1.2.10
>
> On Fri, 29 Apr 2005, Ceki Gülcü wrote:
>
> |
> | Log4j developers are proud to announce the availability of log4j
> | version 1.2.10. This version adds native support for SLF4J, along with
> | a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
> | intended to serve as a simple facade for various logging APIs allowing
> | to the end-user to plug in the desired implementation at deployment
> | time. For more details about SLF4J, see
> |
> | http://www.slf4j.org
> |
> | You can download log4j version 1.2.10 at
> |
> | http://logging.apache.org/site/binindex.html
>
> Fantastic.
>
> So the trace-level does NOT get in the 1.2 branch, where NO NEW
> DEVELOPMENT should enter, but this TOTALLY new SLF4j thing, ramled
> together in very short time, (which I do know is "UGLI MkII") gets _thrown
> in_ and released even w/o any vote, by the totalitarian ruler of log4j???
>
> What the .... is happening, really?
>
> <bad rant>Someone just gotta fork this piece of code now, and get some
> actual new releases with features that people actually seek.</bad rant>
>
> Regards,
> Endre.
>
>
> ---------------------------------------------------------------------
> 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: Release of log4j version 1.2.10
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Fri, 29 Apr 2005, Ceki Gülcü wrote:
|
| Log4j developers are proud to announce the availability of log4j
| version 1.2.10. This version adds native support for SLF4J, along with
| a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
| intended to serve as a simple facade for various logging APIs allowing
| to the end-user to plug in the desired implementation at deployment
| time. For more details about SLF4J, see
|
| http://www.slf4j.org
|
| You can download log4j version 1.2.10 at
|
| http://logging.apache.org/site/binindex.html
Fantastic.
So the trace-level does NOT get in the 1.2 branch, where NO NEW
DEVELOPMENT should enter, but this TOTALLY new SLF4j thing, ramled
together in very short time, (which I do know is "UGLI MkII") gets _thrown
in_ and released even w/o any vote, by the totalitarian ruler of log4j???
What the .... is happening, really?
<bad rant>Someone just gotta fork this piece of code now, and get some
actual new releases with features that people actually seek.</bad rant>
Regards,
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Release of log4j version 1.2.10
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
It would have been nice to have a vote on this release, no? ;)
No big deal. Thanks for putting it together so quickly.
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management / School of Engineering
Cambridge, MA USA
yoavsh@sloan.mit.edu / yoavs@computer.org
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: Friday, April 29, 2005 2:13 PM
> To: log4j-dev@logging.apache.org
> Cc: log4j-user@logging.apache.org
> Subject: Release of log4j version 1.2.10
>
>
> Log4j developers are proud to announce the availability of log4j
> version 1.2.10. This version adds native support for SLF4J, along with
> a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
> intended to serve as a simple facade for various logging APIs allowing
> to the end-user to plug in the desired implementation at deployment
> time. For more details about SLF4J, see
>
> http://www.slf4j.org
>
> You can download log4j version 1.2.10 at
>
> http://logging.apache.org/site/binindex.html
>
>
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> 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: Release of log4j version 1.2.10
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Fri, 29 Apr 2005, Ceki Gülcü wrote:
|
| Log4j developers are proud to announce the availability of log4j
| version 1.2.10. This version adds native support for SLF4J, along with
| a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is
| intended to serve as a simple facade for various logging APIs allowing
| to the end-user to plug in the desired implementation at deployment
| time. For more details about SLF4J, see
|
| http://www.slf4j.org
|
| You can download log4j version 1.2.10 at
|
| http://logging.apache.org/site/binindex.html
Fantastic.
So the trace-level does NOT get in the 1.2 branch, where NO NEW
DEVELOPMENT should enter, but this TOTALLY new SLF4j thing, ramled
together in very short time, (which I do know is "UGLI MkII") gets _thrown
in_ and released even w/o any vote, by the totalitarian ruler of log4j???
What the .... is happening, really?
<bad rant>Someone just gotta fork this piece of code now, and get some
actual new releases with features that people actually seek.</bad rant>
Regards,
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org