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 bu...@apache.org on 2008/08/02 22:27:01 UTC
DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
https://issues.apache.org/bugzilla/show_bug.cgi?id=43204
Thorbjørn Ravn Andersen <th...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #7 from Thorbjørn Ravn Andersen <th...@gmail.com> 2008-08-02 13:27:00 PST ---
If this result in log4j requiring an 5+ JVM, I do not think it should go in the
1.2.x release as it would break backwards compatability.
I would also suggest using slf4j to do the logging with log4j as the backend as
it provides the delayed log string construction with {}-markers.
Hence I suggest this bug to be a WONTFIX.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Ralph Goers <Ra...@dslextreme.com>.
Thorbjørn Ravn Andersen wrote:
> Ralph Goers skrev den 03-08-2008 21:45:
>>
>>>
>> 1.2 is the only current version. 1.3 has been discontinued. The basic
>> work to start 2.0 has been done. A branch has been created for the
>> initial 2.0 work at
>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/.
>> Jira has been setup to capture all the work for 2.0 at
>> https://issues.apache.org/jira/browse/LOG4J2.
> I am aware of that.
>
>>
>> I expect to start doing stuff in the branch within the next few weeks.
> Interesting. What are you planning to do and what are your goals?
Take a look at the Jira issues that are already there. I imagine at
first it will just be some cleanup work and going through and making
Java 5 improvements. My goal is to end up with a cleaner architecture
with some additional features. Unfortunately, I can't use Log4j in the
application's in my environment right now because it is missing a
critical feature. I will need something similar to Logback's TurboFilter
before I can use it.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Ralph Goers skrev den 03-08-2008 21:45:
>
>>
> 1.2 is the only current version. 1.3 has been discontinued. The basic
> work to start 2.0 has been done. A branch has been created for the
> initial 2.0 work at
> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/.
> Jira has been setup to capture all the work for 2.0 at
> https://issues.apache.org/jira/browse/LOG4J2.
I am aware of that.
>
> I expect to start doing stuff in the branch within the next few weeks.
Interesting. What are you planning to do and what are your goals?
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Ralph Goers skrev den 05-08-2008 03:42:
> I don't think you looked carefully enough. Fixing some of the way
> things are currently implemented will probably break compatibility.
> For example, getting rid of Category - which has been deprecated for
> years.
That is true. So 100% binary compatability will not be kept.
> Creating a good implementation of LocationInfo requires Java 5 as that
> is when Thread.getStackTrace() became available. nio didn't become
> available until 1.4. Frankly, I have zero interest in working on a
> log4j that doesn't have Java 5 as a minimum. Log4j is "good enough"
> for older Java releases but real improvements need to be made.
I'm looking forward to seeing what you specifically have in mind. There
are probably a lot of things I have missed living firmly in the pre-1.5
world (we have to be able to run on plain AS/400 installations where 1.3
is the only JVM available).
> One way or another, JBoss and log4j need to play better together. I
> created https://issues.apache.org/jira/browse/LOG4J2-18 just for that.
> Feel free to update it with your thoughts.
I'll have a look at it
>>
> The point of the Jira issues was to do exactly that. I suggest that
> instead of posting the ideas here where they will probably be
> forgotten that you add them as Jira issues. Then go ahead and start
> figuring out how to implement them.
I know. Perhaps it is just a matter of habit, but I like to discuss things before creating the issues.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Ralph Goers <Ra...@dslextreme.com>.
Thorbjørn Ravn Andersen wrote:
> Ralph Goers skrev den 03-08-2008 21:45:
>> 1.2 is the only current version. 1.3 has been discontinued. The basic
>> work to start 2.0 has been done. A branch has been created for the
>> initial 2.0 work at
>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/.
>> Jira has been setup to capture all the work for 2.0 at
>> https://issues.apache.org/jira/browse/LOG4J2.
>>
>> I expect to start doing stuff in the branch within the next few weeks.
> I looked through the issues and there is as nothing that springs in my
> eye as particularily warranting a version 2 (except that to change JVM
> level a version number change is needed, and what benefit will
> changing source code to use e.g. generics bring that warrants dropping
> 1.2, 1.3 and 1.4 as supported platforms?).
> TurboFilter functionality would be nice, but should be possible to
> build in without dropping backwards compatability, so it could be
> added to 1.2 instead.
I don't think you looked carefully enough. Fixing some of the way things
are currently implemented will probably break compatibility. For
example, getting rid of Category - which has been deprecated for years.
Creating a good implementation of LocationInfo requires Java 5 as that
is when Thread.getStackTrace() became available. nio didn't become
available until 1.4. Frankly, I have zero interest in working on a log4j
that doesn't have Java 5 as a minimum. Log4j is "good enough" for older
Java releases but real improvements need to be made.
>
> I can additionally think of these things that would be nice to have:
>
> * configuration "scopes" - e.g. a JBoss configuration file along with
> a web application file mess each other up. It would be nice if they
> could have seperate root loggers which did not step on each others
> toes. This might also be able to solve the "log4j cannot use log4j
> to log" issue.
One way or another, JBoss and log4j need to play better together. I
created https://issues.apache.org/jira/browse/LOG4J2-18 just for that.
Feel free to update it with your thoughts.
>
> * A "log to console only" behaviour if no configuration is active, to
> make the default behaviour the same as for the other logging frameworks.
Agree.
>
> * Support of ZeroConf in the standard loggers (where appropriate), as
> network sockets are the currently best way to do inter-JVM
> communication which is necessary to use Chainsaw or an Eclipse plugin
> etc or to do centralized logging. People who have not used OS X have
> not seen how elegant "just works" can be done. The work done in
> chainsaw is just the beginning.
>
> * Before any work is done to improve performance, care should be taken
> to be able to compare "before and after" to see if performance
> actually improved.
Yes - it is very important to have tests to continually measure that. I
already have one that I use.
>
>
> At this point in time I think it would be very beneficial to create a
> specification of requirements to be able to discuss what work should
> be done, and to determine when the next version is ready :) Otherwise
> it might be hard to collaborate on getting there.
>
> Just my 2 cents...
>
The point of the Jira issues was to do exactly that. I suggest that
instead of posting the ideas here where they will probably be forgotten
that you add them as Jira issues. Then go ahead and start figuring out
how to implement them.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jacob Kjome wrote:
> I believe the threading model is a big reason for moving to version 2. Please
> read the archives about threading/deadlock issues.
>
> Jake
>
>
Did that get covered by any of the Jira issues? If not (and I don't
think so), please add it.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Jacob Kjome <ho...@visi.com>.
I believe the threading model is a big reason for moving to version 2. Please
read the archives about threading/deadlock issues.
Jake
Thorbjørn Ravn Andersen wrote:
> Ralph Goers skrev den 03-08-2008 21:45:
>> 1.2 is the only current version. 1.3 has been discontinued. The basic
>> work to start 2.0 has been done. A branch has been created for the
>> initial 2.0 work at
>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/.
>> Jira has been setup to capture all the work for 2.0 at
>> https://issues.apache.org/jira/browse/LOG4J2.
>>
>> I expect to start doing stuff in the branch within the next few weeks.
> I looked through the issues and there is as nothing that springs in my
> eye as particularily warranting a version 2 (except that to change JVM
> level a version number change is needed, and what benefit will changing
> source code to use e.g. generics bring that warrants dropping 1.2, 1.3
> and 1.4 as supported platforms?).
> TurboFilter functionality would be nice, but should be possible to build
> in without dropping backwards compatability, so it could be added to
> 1.2 instead.
>
> I can additionally think of these things that would be nice to have:
>
> * configuration "scopes" - e.g. a JBoss configuration file along with a
> web application file mess each other up. It would be nice if they
> could have seperate root loggers which did not step on each others
> toes. This might also be able to solve the "log4j cannot use log4j to
> log" issue.
>
> * A "log to console only" behaviour if no configuration is active, to
> make the default behaviour the same as for the other logging frameworks.
>
> * Support of ZeroConf in the standard loggers (where appropriate), as
> network sockets are the currently best way to do inter-JVM communication
> which is necessary to use Chainsaw or an Eclipse plugin etc or to do
> centralized logging. People who have not used OS X have not seen how
> elegant "just works" can be done. The work done in chainsaw is just the
> beginning.
>
> * Before any work is done to improve performance, care should be taken
> to be able to compare "before and after" to see if performance actually
> improved.
>
>
> At this point in time I think it would be very beneficial to create a
> specification of requirements to be able to discuss what work should be
> done, and to determine when the next version is ready :) Otherwise it
> might be hard to collaborate on getting there.
>
> Just my 2 cents...
>
> --
>
> Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
>
>
> ---------------------------------------------------------------------
> 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: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Ralph Goers skrev den 03-08-2008 21:45:
> 1.2 is the only current version. 1.3 has been discontinued. The basic
> work to start 2.0 has been done. A branch has been created for the
> initial 2.0 work at
> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/.
> Jira has been setup to capture all the work for 2.0 at
> https://issues.apache.org/jira/browse/LOG4J2.
>
> I expect to start doing stuff in the branch within the next few weeks.
I looked through the issues and there is as nothing that springs in my
eye as particularily warranting a version 2 (except that to change JVM
level a version number change is needed, and what benefit will changing
source code to use e.g. generics bring that warrants dropping 1.2, 1.3
and 1.4 as supported platforms?).
TurboFilter functionality would be nice, but should be possible to build
in without dropping backwards compatability, so it could be added to
1.2 instead.
I can additionally think of these things that would be nice to have:
* configuration "scopes" - e.g. a JBoss configuration file along with a
web application file mess each other up. It would be nice if they
could have seperate root loggers which did not step on each others
toes. This might also be able to solve the "log4j cannot use log4j to
log" issue.
* A "log to console only" behaviour if no configuration is active, to
make the default behaviour the same as for the other logging frameworks.
* Support of ZeroConf in the standard loggers (where appropriate), as
network sockets are the currently best way to do inter-JVM communication
which is necessary to use Chainsaw or an Eclipse plugin etc or to do
centralized logging. People who have not used OS X have not seen how
elegant "just works" can be done. The work done in chainsaw is just the
beginning.
* Before any work is done to improve performance, care should be taken
to be able to compare "before and after" to see if performance actually
improved.
At this point in time I think it would be very beneficial to create a
specification of requirements to be able to discuss what work should be
done, and to determine when the next version is ready :) Otherwise it
might be hard to collaborate on getting there.
Just my 2 cents...
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Ralph Goers <Ra...@dslextreme.com>.
Thorbjørn Ravn Andersen wrote:
> Ralph Goers skrev den 03-08-2008 17:23:
>> I don't think you got the point I was trying to make. I fully agree
>> that some bugs can't be fixed in 1.2.x. I fully agree that they
>> should be resolved in bugzilla. But as they are moved to WONTFIX here
>> a corresponding issue should be opened in Jira for log4j2 so that it
>> can be determined if it is appropriate to be fixed in that version. I
>> really don't want to have to scour bugzilla to find all these cases
>> if I don't have to.
> Can we agree that WONTFIX'es are not bugs but possibly enhancement
> requests?
>
> Your suggestion is sound, but I think that the work will be somewhat
> redundant. Allow me to explain.
>
> I have understood that at the moment log4j is version 1.2 only as the
> 1.3 has been discontinued (and apparently is now logback), so there is
> no version 2 in the horizont and - more importantly - no particular
> reason for a version 2. Hence I think that the best approach is to
> postpone any work with log4j version 2 including issue migration until
> a version 2 road map is being worked out. At that time it makes sense
> to look at ALL the bugzilla issues to see what would be reasonable to
> put in the road map.
>
1.2 is the only current version. 1.3 has been discontinued. The basic
work to start 2.0 has been done. A branch has been created for the
initial 2.0 work at
https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/.
Jira has been setup to capture all the work for 2.0 at
https://issues.apache.org/jira/browse/LOG4J2.
I expect to start doing stuff in the branch within the next few weeks.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Ralph Goers skrev den 03-08-2008 17:23:
> I don't think you got the point I was trying to make. I fully agree
> that some bugs can't be fixed in 1.2.x. I fully agree that they should
> be resolved in bugzilla. But as they are moved to WONTFIX here a
> corresponding issue should be opened in Jira for log4j2 so that it can
> be determined if it is appropriate to be fixed in that version. I
> really don't want to have to scour bugzilla to find all these cases if
> I don't have to.
Can we agree that WONTFIX'es are not bugs but possibly enhancement requests?
Your suggestion is sound, but I think that the work will be somewhat
redundant. Allow me to explain.
I have understood that at the moment log4j is version 1.2 only as the
1.3 has been discontinued (and apparently is now logback), so there is
no version 2 in the horizont and - more importantly - no particular
reason for a version 2. Hence I think that the best approach is to
postpone any work with log4j version 2 including issue migration until a
version 2 road map is being worked out. At that time it makes sense to
look at ALL the bugzilla issues to see what would be reasonable to put
in the road map.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Ralph Goers <Ra...@dslextreme.com>.
Thorbjørn Ravn Andersen wrote:
> Ralph Goers skrev den 03-08-2008 06:22:
>> A number of issues have comments here that they won't be fixed in
>> 1.2. Rather than just marking them to WONTFIX or closed wouldn't it
>> be more appropriate to create a corresponding issue in Jira (where
>> appropriate) for log4j2 so it can be considered?
>
> Please note that I am suggesting WONTFIX instead of just setting the
> status, to start a discussion of what should be done as issues should
> not be in the NEW state forever. If there is concensus that this will
> not be fixed in log4j 1.2 the issue will not as such go away and can
> be reopened later. Enhancement requests can also be added to
> http://wiki.apache.org/logging-log4j/Log4jRequestedFeatures
>
> Also log4j 1.2 version should be kept stable - it should be possible
> to replace any 1.2.x jar directly with a 1.2.y jar (where y>x) with
> identical behaviour. This puts rather strong restrictions on what can
> be changed.
>
I don't think you got the point I was trying to make. I fully agree that
some bugs can't be fixed in 1.2.x. I fully agree that they should be
resolved in bugzilla. But as they are moved to WONTFIX here a
corresponding issue should be opened in Jira for log4j2 so that it can
be determined if it is appropriate to be fixed in that version. I really
don't want to have to scour bugzilla to find all these cases if I don't
have to.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Ralph Goers skrev den 03-08-2008 06:22:
> A number of issues have comments here that they won't be fixed in 1.2.
> Rather than just marking them to WONTFIX or closed wouldn't it be more
> appropriate to create a corresponding issue in Jira (where
> appropriate) for log4j2 so it can be considered?
Please note that I am suggesting WONTFIX instead of just setting the
status, to start a discussion of what should be done as issues should
not be in the NEW state forever. If there is concensus that this will
not be fixed in log4j 1.2 the issue will not as such go away and can be
reopened later. Enhancement requests can also be added to
http://wiki.apache.org/logging-log4j/Log4jRequestedFeatures
Also log4j 1.2 version should be kept stable - it should be possible to
replace any 1.2.x jar directly with a 1.2.y jar (where y>x) with
identical behaviour. This puts rather strong restrictions on what can
be changed.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String
formatter, stack trace inspection
Posted by Ralph Goers <Ra...@dslextreme.com>.
A number of issues have comments here that they won't be fixed in 1.2.
Rather than just marking them to WONTFIX or closed wouldn't it be more
appropriate to create a corresponding issue in Jira (where appropriate)
for log4j2 so it can be considered?
bugzilla@apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=43204
>
>
> Thorbjørn Ravn Andersen <th...@gmail.com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |NEEDINFO
>
>
>
>
> --- Comment #7 from Thorbjørn Ravn Andersen <th...@gmail.com> 2008-08-02 13:27:00 PST ---
> If this result in log4j requiring an 5+ JVM, I do not think it should go in the
> 1.2.x release as it would break backwards compatability.
>
> I would also suggest using slf4j to do the logging with log4j as the backend as
> it provides the delayed log string construction with {}-markers.
>
> Hence I suggest this bug to be a WONTFIX.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org