Problem with Log4j (Configuration)
Apologies are mine if this issue is discussed already. I have two different applications i-e two separate jar files (ApplicationA.jar and ApplicationB.jar). Both use log4j for logging to separate files (A.txt and B.txt). Now the scenario is ApplicationB uses ApplicationA jar file. I have placed ApplicationA.jar and log4j.jar in WEB_INF/lib folder of ApplicationB. When ApplicationB runs, I expect to get logs in different files but unfortunately this does not happen. ApplicationA makes some logging in B.txt and ApplicationB in A.txt. Though both are using different configuration files. Is this normal? What is the solution to the problem? Thanking in advance. Amir ___ No banners. No pop-ups. No kidding. Make My Way your home on the Web - http://www.myway.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problems with chainsaw build
Scott, The ExpressionFilter&LogFilePatternReceiver/ORO dependency is related but quite distinct from the problem discovered by Curt. As I was expecting a different approach, I was surprised and a little confused by the changes in your latest commit to build.xml. Your changes are certainly not intrusive from the perspective of the "log4j.jar" target. However, I don't think it does justice to the o.a.l.rules package. We should revisit the issue of adding the rules package to log4j.jar and its ORO dependency at a later juncture, after things calm down. How does that sound to you? At 05:20 PM 12/16/2004, Scott Deboy wrote: I'm -1 on reverting. The question is if the chainsaw jar target should be skipped if ORO is missing. ORO's presence is not -critical- in Chainsaw's case. If it were, I would agree with the revert (I wouldn't have made the commit). If the ORO jar is not available when Chainsaw is running (and now compiling the target, after last night's commit), everything works fine - the only feature missing is the 'LIKE' rule in expressions. Again, the expression syntax and rule package were designed to provide functionality in Chainsaw, but are useful outside of Chainsaw (ExpressionFilter). I can't see a reason why folks wouldn't want to download ORO and use it, but the lack of ORO support will not prevent Chainsaw from working. My most recent commit to LogFactory also allows folks to write their own LikeRule using JDK1.4's java.util.regex package if they wanted. Scott -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problems with chainsaw build
I'm -1 on reverting. The question is if the chainsaw jar target should be skipped if ORO is missing. ORO's presence is not -critical- in Chainsaw's case. If it were, I would agree with the revert (I wouldn't have made the commit). If the ORO jar is not available when Chainsaw is running (and now compiling the target, after last night's commit), everything works fine - the only feature missing is the 'LIKE' rule in expressions. Again, the expression syntax and rule package were designed to provide functionality in Chainsaw, but are useful outside of Chainsaw (ExpressionFilter). I can't see a reason why folks wouldn't want to download ORO and use it, but the lack of ORO support will not prevent Chainsaw from working. My most recent commit to LogFactory also allows folks to write their own LikeRule using JDK1.4's java.util.regex package if they wanted. Scott -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thu 12/16/2004 5:05 AM To: Log4J Users List Cc: Subject:Re: problems with chainsaw build I'd like to echo Curt's words. There was a bug in our Ant build.xml file due to the counter-intuitive way Ant handles dependencies and their conditions. http://ant.apache.org/faq.html#stop-dependency Q: I have a target I want to skip if a property is set, so I have unless="property" as an attribute of the target, but all the targets this target depends on are still executed. Why? A: The list of dependencies is generated by Ant before any of the targets are run. This allows dependent targets, such as an init target, to set properties that can control the execution of the targets higher in the dependency graph. This is a good thing. However, when your dependencies break down the higher-level task into several smaller steps, this behavior becomes counter-intuitive. There are a couple of solutions available: - Put the same condition on each of the dependent targets. - Execute the steps using , instead of specifying them inside the depends attribute. The fix is in plain view for everyone to see: "Put the same condition on each of the dependent targets." Thus, the remedy consists of changing the line to In other words, simply repeating the condition for the "build.chansaw" target would have sufficed. Scott, may I propose to revert your changes to the RuleFactory class? I think instanciation by introspection introduces unnecessary complexity in this case. At 04:37 AM 12/16/2004, Curt Arnold wrote: >On Dec 15, 2004, at 8:15 PM, Paul Smith wrote: > >>I just did an "ant clean" then an "ant jar" and the chainsaw jar DOES >>contain LogUI. >> >>So unless the local environment is missing something that is preventing >>it from building all of Chainsaw (maybe regexp library not there?). >> >>Curt, maybe you could email me or Scott the jar that gets built, along >>with the output of whatever "ant jar" gives you. > >The partial chainsaw jar only occurs when chainsaw-libraries-present is >not set. In that case, the body of the build.chainsaw task is skipped due >to the if condition not being set. However, chainsaw.jar doesn't have the >same if condition so its body will be executed regardless of the state of >chainsaw-libraries-present. The easiest way to reproduce it is to rename >your build.properties so jakarta-oro is not located (might need to make >sure it is off the classpath too). > >I had not been trying to build chainsaw and had not set a build.properties >file since it is not necessary to build a functional log4j. > >One approach would be to add the if condition to the chainsaw.jar task, so >that if the body of build.chainsaw is skipped the body of the chainsaw.jar >task is skipped. Adding that condition would result in only log4j.jar >being created under the conditions described. > >The other would be to fail build.chainsaw if the libraries were >missing. To build just log4j.jar, you would need to build the log4j.jar >target. > > >p.s. Ant FAQ on if and unless not affecting dependent tasks: >http://ant.apache.org/faq.html#stop-dependency. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with chainsaw build
I'd like to echo Curt's words. There was a bug in our Ant build.xml file due to the counter-intuitive way Ant handles dependencies and their conditions. http://ant.apache.org/faq.html#stop-dependency Q: I have a target I want to skip if a property is set, so I have unless="property" as an attribute of the target, but all the targets this target depends on are still executed. Why? A: The list of dependencies is generated by Ant before any of the targets are run. This allows dependent targets, such as an init target, to set properties that can control the execution of the targets higher in the dependency graph. This is a good thing. However, when your dependencies break down the higher-level task into several smaller steps, this behavior becomes counter-intuitive. There are a couple of solutions available: - Put the same condition on each of the dependent targets. - Execute the steps using , instead of specifying them inside the depends attribute. The fix is in plain view for everyone to see: "Put the same condition on each of the dependent targets." Thus, the remedy consists of changing the line to In other words, simply repeating the condition for the "build.chansaw" target would have sufficed. Scott, may I propose to revert your changes to the RuleFactory class? I think instanciation by introspection introduces unnecessary complexity in this case. At 04:37 AM 12/16/2004, Curt Arnold wrote: On Dec 15, 2004, at 8:15 PM, Paul Smith wrote: I just did an "ant clean" then an "ant jar" and the chainsaw jar DOES contain LogUI. So unless the local environment is missing something that is preventing it from building all of Chainsaw (maybe regexp library not there?). Curt, maybe you could email me or Scott the jar that gets built, along with the output of whatever "ant jar" gives you. The partial chainsaw jar only occurs when chainsaw-libraries-present is not set. In that case, the body of the build.chainsaw task is skipped due to the if condition not being set. However, chainsaw.jar doesn't have the same if condition so its body will be executed regardless of the state of chainsaw-libraries-present. The easiest way to reproduce it is to rename your build.properties so jakarta-oro is not located (might need to make sure it is off the classpath too). I had not been trying to build chainsaw and had not set a build.properties file since it is not necessary to build a functional log4j. One approach would be to add the if condition to the chainsaw.jar task, so that if the body of build.chainsaw is skipped the body of the chainsaw.jar task is skipped. Adding that condition would result in only log4j.jar being created under the conditions described. The other would be to fail build.chainsaw if the libraries were missing. To build just log4j.jar, you would need to build the log4j.jar target. p.s. Ant FAQ on if and unless not affecting dependent tasks: http://ant.apache.org/faq.html#stop-dependency. -- Ceki Gülcü The complete log4j manual: http://qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
question regarding roll over mechanism
Hi ! I am using the org.apache.log4j.RollingFileAppender to roll log files once they reach the size of 10MB (I am using log4j version 1.2.8). assuming in my log folder i have the following files: file.log file.log.1 file.log.2 file.log.3 once i have a roll over (file.log reaches 10MB) there is a renaming of all the files: file.log->file.log.1 file.log.1->file.log.2 file.log.2->file.log.3 file.log.3->file.log.4 is this rollover mechanism configurable ? meaning, can i determine that instead of that mechanism i want the logs to roll in an ascending way ? assuming i have file.log file.log.1 the next roll over will create file.log.2 from file.log are there any other changes in that mechanism in the new versions ? thanks, Shai Simchi Invoke Solutions Ltd. +972-3-5756828 (ext. 206) +972-66-227746 (mobile) +972-3-5756829 (Fax) mailto:[EMAIL PROTECTED] www.invoke.com
Problem with Log4j ( Configuration)
Apologies are mine if this issue is discussed already.
