MDCOrderFilter.java gives Eclipse errors in trunk
Hi. I have run mvn eclipse:eclipse on trunk, and Eclipse 3.6.1 then complains about MDCOrderFilter not being in the correct location for package org.apache.log4j.util. Allowing Eclipse to move it to said package removes compilation errors. Is this expected behaviour? Thanks, -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: DO NOT REPLY [Bug 49354] New: XMLLayout writes illegal characters to XML file
Den 28/05/10 16.34, bugzi...@apache.org skrev: XMLLayout should ensure that what it write is legal XML, either by escaping illegal characters, removing them, or replacing them. Until that happens the best you can do, is subclass XMLLayout to do the processing you need (removing invalid unicode characters, etc). It is not hard. I've done the same with the similar class in logback. -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: Improving log4j so it can easily be used with servlet logging
Den 30/05/10 23.12, Curt Arnold skrev: I don't have this in code or in the JIRA, but I have mentioned in recent threads the idea of a user-supplied context object in logging calls. Currently log4j has a thread associated context (the MDC and NDC) and there are JVM level context (line ending separator), but there is no concept of a user-supplied context unless embedded in the message parameter. In this case, the logging call is operating in the context of the servlet request, and you could do pass the servlet as the user-context object. A servlet appender could check if the user context object was a Servlet and if so delegate to its log method. We could also add patterns for %ipaddr, %ipport, etc, that would attempt to recognize the user-context object and extract that info if it could recognize the type. I am unsure of what you describe. Could you write some pseudocode showing what you mean? -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: Improving log4j so it can easily be used with servlet logging
Den 30/05/10 21.34, Ralph Goers skrev:
Wouldn't it make more sense for the LoggerContext to have a reference to the
ServletContext? The Appender could then do
if (getContext().getServletContext() != null) {
getContext().getServletContext().log(event.getFormattedMessage());
}
I do not know. I am unfamiliar with what the LoggerContext provides.
Are you suggesting that for each and every possible sub-context you will
provide a field in the LoggerContext?
Note that if the servlet adds its name to the MDC then all log records will
have this available.
To be honest though, I would have expected the desire would be to have the
ServletContext's log methods route to Log4j, not the other way around.
The reason is simple. There is no guarantee that any J2EE container can
or will allow access to the filesystem. Using the servlet log-method is
the _ONLY_ well-defined way to log things inside a J2EE container
without needing to make assumptions and manual configurations (remember
the container doesn't help).
Possible assumptions may be:
* I can access the file system.
* Current working directory can be used (for writing or starting navigation)
* The JVM provides environment variable which can be used to locate the
user.home of the operating system user running the JVM.
* The JVM is allowed to write in user.home.
I like debug logs placed in the filesystem, but I also like to be able
to send log messages to the standard log mechanism. The latter I cannot
do right now.
--
Thorbjørn Ravn Andersen ...plus... Tubular Bells!
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Improving log4j so it can easily be used with servlet logging
There is one more thing that I would really like to see in log4j 2.0, namely the ability for a servlet to log to a servlet container using log4j (and in slf4j too but that is a different story). Currently that cannot be done, because there is no way for the code asking for the logger to pass a this reference to the logging framework. I would suggest that in log4j 2.0 the LoggerManager.getLogger() signature is changed to accept the class (as now), and a varargs of Objects. The objects are passed to the appender when needing to do the actual logging, allowing a ServletLoggerAppender to look for any object extending GenericServlet and invoke its log method. For client code it would mean that the logger object was retreived similar to: Logger log = Logger.getLogger(this.getClass(), this); We might even consider making the rule in log4j 2.0 that the name of the logger is the full name of the class of the first object[2]. In that case we could make do with: Logger log = Logger.getLogger(this); This would most likely also result in much other code being cleaner by allowing to drop the getClass() clause. What do you think? [1] http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/GenericServlet.html#log%28java.lang.String%29 [2] For backwards compatability instances of Class should be treated slightly different :) -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: A new thread for log4j 2.0 discussion (Was Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12
Den 22/05/10 04.44, Curt Arnold skrev:
1. I first created an API that had the features I was looking for. That is in
log4j2-api. While it supports logging a String or an Object it really uses a
Message interface which is valuable as it allows users to log self-describing
objects in a convenient manner.
My thinking was the message interface would end up so minimal that might as
well just use Object.
Would it be feasible to use Object so any object can be logged, but
support one or more interfaces that allow a given object to provide more
information to the logger framework?
Also, I have had an issue where the I wanted the toString() method on
the object to be logged to be delayed as much as possible (somewhat
helped with the {}-construct in slf4j). This might be doable with a
specific log interface.
--
Thorbjørn Ravn Andersen ...plus... Tubular Bells!
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [jira] Commented: (LOG4J2-33) Support Annotations
Den 15/05/10 08.29, Ralph Goers (JIRA) skrev: My experimental branch uses annotations for Logj components, but still does not address my desire to allow applications to inject logging. Annotations are just meta-information. You will need the classloader to take special action on them for anything to happen. I am cracking the nut of how to get @Inject Logger log to work properly with slf4j in a JEE 6 setting - I believe it is a case of a correctly placed @Producer. Is this similar to what you want to solve? -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12-api/src/main/java/ log4j12-api/src/main/java/o
Den 14/05/10 09.22, Ralph Goers skrev: 2. I don't like the way Logback binds to the implementation. I used a technique I had used in a previous logging framework and used a file to define the implementation class. In theory, the API could be modified to support multiple logging implementation simultaneously, although I have no plans to implement that. You mean slf4j binding to logback? I think the work done with standardizing the Seam approach in JEE 6 (which I am reading up on) will benefit also slf4j, since it will basically handle the API-implementation binding, so that the logging framework will not have to. 7, All internal components use the logger API for status reporting. A specific StatusLogger provides the implementation. I like that. It is nice that you can use logging even if you are coding stuff inside a logger. -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: svn commit: r909868 - in /logging/log4j/trunk: src/changes/ src/main/java/org/apache/log4j/ src/main/java/org/apache/log4j/helpers/ tests/src/java/org/apache/log4j/ tests/witness/
Ceki Gülcü skrev: The process that I followed was to examine to the logback code to determine what prudent mode was, which I then described as part of the bug report and then implemented from the description. The fragments are similar since there aren't that many ways to get a lock on a channel, reposition the channel to the end of the file, write a string, and release a lock. What a load of horse crap. The prudent mode feature in logback was requested by a paying customer. It took me a week, working full-time, to bring the code and its accompanying battery of tests to its current state. You got a there in a few hours and proceeded to resolve 5 other log4j bugs all in the same evening. You must be a genius. From what I see in the code the actual method implementing this facility is less than 20 lines of code. I fully understand that these lines of code may have been extremely hard to get right. The question here is then - if the code wasn't copy-pasted but understood and then described in wording in the bug as Curt said, and the implementation done from the description in the bug, wouldn't this be perfectly fine? Since the code base around the method in question basically has the same heritage - you might even call it a backport from log4j version 2 to log4j version 1.2, it would to me seem quite reasonable to expect that the resulting code would be similar. -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: Final bug call for log4j 1.2.16
Curt Arnold skrev: FYI: I'm hoping to be able to cut a release candidate for 1.2.16 tomorrow. I've put a tentative release date of October 21th into the changes log. My intent is to use the intervening time to prepare some of the companions, log4j-extras, at minimum for a simultaneous release. I'm expecting to prepare the build on a Ubuntu 8.04 image on Amazon Web Services with Sun's Java 6 and Maven 2.2.1. I'll update BUILD-INFO.txt to give line-by-line instructions on setting up the instance and building the release. Great. Using LTS versions for building releases is probably the best way to ensure reproducability. I'll have a look at the bug reports... -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 12-12-2008 16:01: To run this test, in addition to junit4.jar, you need to have slf4j-api.jar, apache-log4j-extras-1.1-SNAPSHOT.jar and log4j.jar on your class path. On my machine the output is: LogMF avg=15251 SLF4J avg=4964 On my machine (which is low on RAM) I get these numbers with JDK 1.5 SLF4J avg=6085 LogMF avg=12582 I understand how you get the LogMF method to write to ytest.log, but not how the slf4j method does it. Would you care to elaborate? This shows that an enabled logging statement runs three times faster when logging via SLF4J than when logging through LogMF, with log4j as the underlying logging framework. Not only is the SLF4J formatter faster, it makes a noticeable difference when the logs are actually written to destination. This is a very substantial difference, so if the LogMF approach is to be used some kind of mechanism should be used to optimize - a weak reference cache of the MessageFormatter with the format string as key - but if the simpler approach is faster I would personally go with that. -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 15-12-2008 11:19: Sure. SLF4J delegates to log4j (via slf4j-log4j12.jar). I now realize that the instructions in my mail of 12-12-2008 did not mention slf4j-log4j12.jar. Did you add slf4j-log4j12.jar to your class path? I must have. I just didn't remember to check before responding to the mail, and thought I missed something in the process. Thank you. I am not doubting, just not understanding, there is a difference O:) -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 11-12-2008 16:04: There is no point in digging into into the archives. Unless you can point to a mistake in the test case I provided yesterday, it irrefutably demonstrates that LogMF does not offer equivalent performance. There is the minor thing that you are not using the result returned by the format routines. Hence the JIT _MAY_ have done optimization tricks influencing the numbers you see. Also you have not shown that the output numbers are statistically representative (i.e. close to the mean of several runs) and how the numbers are if you test slf4J before log4mf (as HotSpot optimizations may kick in while testLogMF is being run). Is the resolution of your nanotime function high enough that the differences over a single format()-invocation is usable for summarizing, i.e. can you inject the measurement code in a real life scenario? -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Paul Smith skrev den 09-12-2008 02:46:
private static String getFormattedMessage(String message,
Object... args) {
String formattedMessage = message;
if (args != null args.length 0) {
formattedMessage = String.format(message, args);
}
return formattedMessage;
}
..
Then the code is changed to:
LogUtils.debug(LOG, Hello %s, your age is %d, name, age);
Now, that bypasses slf4j completely, and maintains source
binary compatibly, and can easily be migrated to.
There was a request recently to make the argument replacement mechanism
more powerful in either slf4j or logback (cannot remember) where Ceki
mentioned that one of the major benefits of the {}-approach was that it
was measurably faster than the StringFormatter in Java.
For this particular purpose I suggest that the fastest approach is
chosen as it will apply to all events actually processed. Would
lifting the slf4j code into log4j be an option - I believe that the
license allows it.
--
Thorbjørn Ravn Andersen ...plus... Tubular Bells!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Jacob Kjome skrev den 07-12-2008 06:04: On 12/6/2008 6:27 AM, Thorbjørn Ravn Andersen wrote: I believe that the positive in decoupling the logging implementation from the application will vastly overshadow any inconvinience in this regard. Most if not all of the work has been done in the slf4j project. Right. Most if not all the work has been done. What is left? SLF4J has succeeded in its aim. Congratulations! And I'm not being facetious here. So, what exactly is the impetus to to modify Log4j 1.2 when existing SLF4J binders work well with it? I believe that Curt Arnold may be somewhat right in that this is a matter of Apache endorsement. This is purely guesswork. I still think that log4j should have a Best practices list, where the use slf4j framework should be on the list for backend independence, to inform the users as early as possible. Also, it seems to me that there is a clear advantage to the SLF4J project in maintaining control of its own development. If there's some fundamental fix that needs to be done to all binders it can be done and released quickly; entirely under the control of one project. Why move part of this control out to external projects? What is the advantage of it? Wouldn't that necessitate Log4j to coordinate its release cycles with SLF4J to a certain extent? Such a burden seems totally unnecessary as they can and have lived happily apart up to now. You have a very valid point here. slf4j has not quite settled down yet - IMO - regarding features and releases so it would make perfect sense to keep log4j and slf4j distinct and disentangled. I'm not sure about this whole JUL has won the API war thing? I guess I'd have to hear more from Curt about why he believes this? I've never even considered using JUL, but maybe that's just me? j.u.l has a few advantages over log4j, one of them being it works without a configuration file :) However, the question of why Log4j has not provided adapters for JUL in the 1.2.xx codebase is probably because it's somewhat of a dead end, development-wise. It is in maintenance mode. It generally works well, but there are fundamental issues (threading) that can't be fixed without breaking compatibility. So, changes are limited to those that preserve compatibility. The upside is that existing users who have written custom extensions can upgrade and pick up fixes without having to worry about breakage. The downside is that the motivation to innovate remains in hibernation until someone gets cracking on Log4j 2.0. I, for one, seem to have less and less time for this as the years go by; sad but true. Other projects have created extra packages containing such auxillary classes to avoid breaking things in the core package. The reason must be another :) Are you *ABSOLUTELY* certain you want to bring in politics in this technical issue? In my opinion it will only mudden the waters! I don't necessarily condone it, but I understand where it comes from. And unless you followed Log4j-1.3/nLog4j/UGLI experience a few years back, you probably won't understand. All I can say is that there's a bit of Dejavu going on here I did not follow the experience a few years back, so I don't understand much. I do understand, however, that apparently this controversy caused a project to fork, so it must have been bad. I propose that log4j implement the SLF4J API directly. This can be done in the next version of log4j, say 1.3 or 2.0. New versions which break stuff have a tendency to gain less adoption from users. Right now it is a bit vague talking about the next version of log4j, as not much is happening which could warrant a new release.It appears to me that most of the logging development taking place at the moment happens in logback. -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 08-12-2008 12:41: Thorbjørn Ravn Andersen wrote: I believe that Curt Arnold may be somewhat right in that this is a matter of Apache endorsement. This is purely guesswork. I still think that log4j should have a Best practices list, where the use slf4j framework should be on the list for backend independence, to inform the users as early as possible. Sigh. My proposal is a wake up call for log4j. The project can go back to slumber or come back to life by providing a valuable new feature to the java developer community. The problem with your proposal is that there is no pressing NEED for doing so. You have yourself provided the library that removed that need! Frankly I see no technical reason for your proposal - the graph you showed was a bit ugly - but not extremely so. Things converged nicely at the slf4j level, which was your intend all along, and which has been very successful. I agree that the log4j is currently in a very uninteresting place developmentwise, but so be it. As long as there hasn't been a consensus on where to go from here - and WHY - it is hard to initiate a coordinated development effort. Poohing my proposal under the pretext that it is a grab at Apache brand is extremely offensive. A little modesty regarding the importance of the Apache or log4j brands, would be a welcome change. As I am not involved with Apache in any other way than being a user of the products, and spent some time reporting bugs here and there, I believe I can say that I do not have any personal interest in protecting Apache or log4j.I believe that slf4j uses the right approach - load time binding - to select logger framework, but I am not singleminded about it. Everything I write is my personal opinion only. I think, however, that the Apache brand is extremely strong in the development community, as it has proven to stay around and has enough mass to ensure that projects stay maintained (and if not, that they are appropriately taken care of). You yourself know how strong the log4j brand is amonst developers, and I believe there was a reason that you chose back then to move it to Apache. It is a top level project, which is an accomplishment in itself. Kudos for that. I am not poohing your proposal, I am wondering what is going on here. Would you care to explain why this suddenly is so important, if the Apache and log4j brands are unimportant? And by the way: For those who don't know I am currently adding stuff to the slf4j-ext sub-project, and the logback-incubator but I am not more involved than that.I am a pragmatic who basically wants to reach a suitable solution which can live forever being maintained as that is traditionally how long code lives in our company. Apache has a very good record in this regard. You have a very valid point here. slf4j has not quite settled down yet - IMO - regarding features and releases so it would make perfect sense to keep log4j and slf4j distinct and disentangled. SLF4J has not settled down? What do you mean exactly? Do mean slf4j-ext (slf4j-extensions) or slf4j-api? I know - as I am providing code for it - that the slf4j-ext project is not settled down, but I was thinking of the API. I have not investigated closely, but since the version numbering is common for all of slf4j it is hard to identify how much or how little has changed and when. If there has been an announcement that slf4j-api is effectively frozen for the rest of the version 1.X's I've unfortunately missed it. (and please don't take any of this personally - rather, consider it an opportunity to respond instead of having to deal with what people THINK you mean :) -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Curt Arnold skrev den 04-12-2008 20:34: As far as I can tell, there is no significant practical advantage to our user community to do a direct implementation of SLF4J in log4j over the facade implementation provided by slf4j.org. I have never seen a significant performance difference between the two approaches and a direct implementation has several strong negatives to the log4j community and users that have been previously discussed. Simply the fact that it is impossible for programs using log4j or java util logging to switch between java.util.logging (the Sun standard) and log4j (the de-facto standard) should be enough to say that a solution must be found.The Commons logging project did not work well, and a revised version which do has not shown up. I believe that the positive in decoupling the logging implementation from the application will vastly overshadow any inconvinience in this regard. Most if not all of the work has been done in the slf4j project. However, I could see a significant political advantage to SLF4J to have an implicit endorsement from the ASF and in my mind that is what this proposal is about. In my mind, java.util.logging has already won the API standardization war years ago, but it has been mostly limited the available appenders and configurators. One of the design goals (https://issues.apache.org/jira/browse/LOG4J2-5) for log4j 2.0 is to have the back-end classes independent of the API, so that the bulk of log4j 2 is isolated from the client's API choice. I find your statement quite interesting. If j.u.l won the standardization war, then how come that there has been no adapter from log4j to j.u.l from this project? That would be the perfect way to migrate to a standards based logging solution. Are you *ABSOLUTELY* certain you want to bring in politics in this technical issue? In my opinion it will only mudden the waters! -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 04-12-2008 21:33: Curt has plainly expressed his feelings. What do others think? I think that the slf4j approach is the right way to select the logging framework, and it is the only implementation of this approach I am aware of. My personal Best Practice list has use slf4j high on the list. As slf4j is an open source project it is not a problem for users to use it and choose the backend they like, but an issue in whether log4j should acknowledge slf4j at all allowing users to avoid reinventing the wheel over and over again, when they find that they need to combine libraries which use java.util.logging and log4j with their own source. I strongly believe that either should the log4j project endorse the practice of using slf4j or provide its own implementation of java.util.logging-over-log4j bridging to give the users the best headstart in the world of large applications with lots of independent libraries. If this proprosal is rejected for any reason, the rejecters should at least initiate an alternative and reasonable solution to the problem of multiple logging frameworks in the same application, as this is a real issue encountered by real programmers. Personally I think that the least complex solution would be either to accept a donation of the log4j-slf4j bridge in the standard log4j distribution or go the whole way with Cekis suggestion. -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Scott Deboy skrev den 04-12-2008 05:22:
I'd like to understand why the Logger trace/debug etc. base methods take a string instead of an object.
I'd like to think there's usefulness in supporting something like
ObjectRenderer or ReflectionPolicy/MapPolicy+RewriteAppender - supporting only
strings makes this difficult.
Whatever we do moving forward, I'd like to see increased support for
properties. MDC and NDC are useful, but something that isn't thread specific
would be useful (one reason why property rewrite policy/rewriteappender were
created was to get around this limitation).
If I understand Ceki correctly it is the MESSAGE that is a String, not
the additional arguments for the formatting part.
The message can contain {}-pairs which is then replaced with additional
arguments - these can be objects. This allows for postponding the
flattening process til after it has been decided that the event will not
be discarded.
On a related note I would like to have better terms than NDC and MDC
as nobody can figure out what they do unless they do a lot of reading.
Additionally the two terms are so similar I tend to confuse the two.
MDC could be Log ThreadMap?
--
Thorbjørn Ravn Andersen ...plus... Tubular Bells!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] when showing a stack trace - include the relative package versions and optional jar name to aid debugging
James.Strachan skrev den 01-09-2008 14:51: Thoughts? I really like this :) Excellent! How did you get the idea? -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j 1.2.16 release plan
Curt Arnold skrev den 13-08-2008 07:16: I've thinking it is likely that we may run into problems with the geronimo artifacts on earlier JVM's. May have to hack the pom.xml and rebuild to get compatible bytecode. The geronimo artifacts are only used for building, not running. Shouldn't that be ok? I'll have a look at your issues. -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sort-of-back-in-action
Curt Arnold skrev den 06-08-2008 00:53: I've been on vacation for a week and the backlog of changes to Bugzilla is daunting. There already was a bug for the log4j 1.2.16 release (bug 43313) and somehow it and the newly introduced one (Bug 45527) need to be reconciled. I haven't reviewed the new bug and my opinion of blocking bugs and Thorbjørn Ravn Andersen's may differ greatly.- Glad you are back in business. The sole reason for 45527 was to have a single point of determining what was pending. To be honest I think I had missed the original bug when getting around to deal with what needs to be done and what doesn't for the 1.2.16 release.My idea is to have an easy way to determine if there is any more work that must be done before releasing. Feel free to mark as a duplicate and move the blockers :) -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plain log4j trunk - mvn install fails
Paul Smith skrev den 04-08-2008 23:25: I have had no problems mvn installing log4j (I've needed to do so a lot because Pinpoint and some other log4j-* projects link against the current SNAPSHOT). I ended up taking a virgin (in log4j regards) Ubuntu box with Java 6, installed latest Maven, pulled out the log4j-trunk and ran mvn install. The only thing I had to do was to delete the jmx reference in pom.xml as this is present in the JDK. Then it built and installed without a hinch (except it took 11 minutes). Glad the error was in my end :) -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plain log4j trunk - mvn install fails
Paul Smith skrev den 07-08-2008 00:03: The only thing I had to do was to delete the jmx reference in pom.xml as this is present in the JDK. Then it built and installed without a hinch (except it took 11 minutes). That 11 minutes will be all the Maven artifacts being downloaded (almost nothing to do with log4j - only a handful of artifacts to get). Having a local Archiva or Nexus proxy close by makes it much much faster! :) (especially for us folks downunder). Don't quite think so, as this was an aging Pentium II 300 MHz with 256 Mb RAM :) I'm pretty sure most of the artifacts was loaded before the final build. -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r682919 - /logging/log4j/trunk/INSTALL
[EMAIL PROTECTED] skrev den 05-08-2008 22:10: Author: carnold Date: Tue Aug 5 13:10:49 2008 New Revision: 682919 URL: http://svn.apache.org/viewvc?rev=682919view=rev Log: Bug 45485: Update INSTALL for elimination of jmxtools.jar dependency Modified: logging/log4j/trunk/INSTALL Modified: logging/log4j/trunk/INSTALL URL: http://svn.apache.org/viewvc/logging/log4j/trunk/INSTALL?rev=682919r1=682918r2=682919view=diff == --- logging/log4j/trunk/INSTALL (original) +++ logging/log4j/trunk/INSTALL Tue Aug 5 13:10:49 2008 @@ -77,7 +77,7 @@ place Maven 2 on the PATH and execute mvn package. The resulting jar will be placed in the target subdirectory. -Three dependencies need to be manually installed since their licenses do +Two dependencies need to be manually installed since their licenses do Great :) Perhaps I was not clear enough. If compiling with a JDK higher than 1.5 the jmx-1_2_1-ri.zip is not necessary either. -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r682879 - in /logging/log4j/trunk: build.properties.sample build.xml pom.xml src/changes/changes.xml src/main/java/org/apache/log4j/jmx/Agent.java
Paul Smith skrev den 06-08-2008 00:22: Yes, thanks, although I _wish_ we could use this slightly different pattern instead (as I'm sure you probably agree): throw new RuntimeException(Failure starting... , e); except it needs 1.4 source compatibility. *sigh*. bummer. It is worse, it needs a 1.4 runtime :( I solved this at work by writing a RootCauseException which behaves like RuntimeException with the extra argument, and then use that for these kind of things. Might be the easiest solution here. -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
plain log4j trunk - mvn install fails
Hi. I am trying to figure out how to build the various subprojects of log4j, and just want to know if it is just my configuration or if Oro is required to run mvn install in log4j trunk? (I also disabled the NTEventAppenderTest in test/build.xml as this is under XP). Is log4j being built by Gump? -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 45493] New: Log4j file getting overwritten
[EMAIL PROTECTED] skrev den 28-07-2008 23:01: residing in a NAS (common shared) drive and all the managed servers point to the same file while logging information from application So you are basically writing in the same file from several places? This is bound to give that kind of problems you describe. There is no file locking in the RollingFileAppender which means that the JVM does not do anything to ensure that the problems you have do not happen. Is there any particular reason why you cannot have a log file per server? If not you can either have a centralized logger doing the writing which all your appenders forward to, or write the file locking yourself. -- Thorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: static logger
Java House skrev den 05-07-2008 16:27: How bad is it, to NOT use static logger; By having the logger variable static it means it is only initialized once when the class is loaded where as a non-static logger is initialized each time you create a new object from the class. If you do this a lot there might be a substantial overhead which is often unnecessary if the logger is the same for all objects. Please note that the object may be used by more than one thread so you should be aware that this might trick your RepositorySelector. -- Thorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: static logger
Java House skrev den 05-07-2008 18:10: O/H Thorbjørn Ravn Andersen έγραψε: Java House skrev den 05-07-2008 16:27: How bad is it, to NOT use static logger; By having the logger variable static it means it is only initialized once when the class is loaded where as a non-static logger is initialized each time you create a new object from the class. If you do this a lot there might be a substantial overhead which is often unnecessary if the logger is the same for all objects. I understand this. I believe that is why it is disrecommended. Please note that the object may be used by more than one thread so you should be aware that this might trick your RepositorySelector. But this is exactly the problem I have by using a static logger object. The logger variable gets value from the last instantiated object which is any of the threads in question. The only way to make this work is if the logger object is not static. Are you familiar with the ThreadLocal class? Sounds to me that that is what you might want to look into. http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html -- THorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Receivers artifacts and Chainsaw
Paul Smith skrev den 04-07-2008 02:02: I think that there should be a core log4j which should cover those classes described in the printed manual, and that all the other stuff which has come up since then should go in one or more extras packages which may have a different release cycle than the core. But there is.. log4j-receivers is a separate maven module with an independent release cycle. There's also log4j-extras. Great. Somehow I must have missed the explanation of this on the web pages, sorry. What is the state of the log4j-receivers and log4j-extras modules? -- THorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Receivers artifacts and Chainsaw
Paul Smith skrev den 04-07-2008 00:46: One of the last tasks to complete before a potential 'release' to the Webstart version of Chainsaw is building a custom Receiver artifact output that does not include the JMSReceiver DBReceiver, both of which require dependent jars that we obviously can't ship (because we don't know what provider they'll need). I plan to add a new output artifact in log4j-receivers that contains this, and have it with a classifier of 'chainsaw-receivers', and have it attached via buildhelper plugin so that it is pushed out as an artifact. A similar approach would be to produce an artifact just containing JMS+DB receivers. There would still be a 'non-classified' binary containing all Receivers as standard. That way Chainsaw can mark a dependency on it's relevant classifier. This would mean that both the Webstart and standalone versions of Chainsaw would require an end-user who wished to use JMSReceiver or DBReceiver could download the 'extras' pack of Receivers, and drop it into the plugins folder together with their provider jars. I think that there should be a core log4j which should cover those classes described in the printed manual, and that all the other stuff which has come up since then should go in one or more extras packages which may have a different release cycle than the core. The reason is the simple that log4j-core for 1.2 is mature code which should get few updates, where the auxillary libraries appears still to be rough here and there, so I think it would be beneficial to have two seperate release tracks. -- Thorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
