DO NOT REPLY [Bug 25355] allow to require "TLS/SSL only" for outgoing mails of your SMTPAppender
https://issues.apache.org/bugzilla/show_bug.cgi?id=25355 --- Comment #3 from Ralf Hauser <[EMAIL PROTECTED]> 2008-08-06 05:21:50 PST --- bug 45053 might have some code relevant for this -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43867] NOPLoggerRepository error during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=43867 --- Comment #55 from Dan Armbrust <[EMAIL PROTECTED]> 2008-08-06 07:17:28 PST --- (In reply to comment #54) > Dan, > > Something sounds suspicious about your description. It doesn't make sense that > reflection would invoke the class initializer if the class has already been > initialized. The Javadoc or JLS would mention it somewhere... > > Did you narrow down the problem to a specific line of code? Was it > Class.getDeclaredFields()? > Didn't make much sense to me either. The stacktrace above shows exactly where the init call happens. And, now I did find it in the javadocs: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Field.html#get(java.lang.Object) -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31179] Implement Chainsaw as Eclipse stand-alone application.
https://issues.apache.org/bugzilla/show_bug.cgi?id=31179 Curt Arnold <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEEDINFO|ASSIGNED --- Comment #4 from Curt Arnold <[EMAIL PROTECTED]> 2008-08-06 07:29:14 PST --- Clearing NEEDINFO. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25355] allow to require "TLS/SSL only" for outgoing mails of your SMTPAppender
https://issues.apache.org/bugzilla/show_bug.cgi?id=25355 Curt Arnold <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEEDINFO|ASSIGNED --- Comment #4 from Curt Arnold <[EMAIL PROTECTED]> 2008-08-06 07:33:47 PST --- Clearing NEEDINFO. Any code involving encryption must be reviewed for export issues prior to committing to the SVN. Any code on this issue should be attached as a patch first and reviewed by the PMC before committing. See http://www.apache.org/dev/crypto.html. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36384] Configuring triggering/rolling policies should be supported through properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=36384
--- Comment #7 from Hugues Pisapia <[EMAIL PROTECTED]> 2008-08-06 09:06:09 PST
---
Created an attachment (id=22396)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22396)
patch to log4j's PropertySetter agaisnt today's code in trunk
Here is a quick patch I've been working on. It basically allows to configure
the appender with an object by providing a class name and then configure the
object via sub-properties.
I've been able to configure the rootLogger with the following properties:
ROOT category ###
log4j.rootLogger=DEBUG, ROOT
log4j.appender.ROOT=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.ROOT.RollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy
log4j.appender.ROOT.RollingPolicy.FileNamePattern=/logs/root.log-%d{-MM-dd-HH-mm}.gz
log4j.appender.ROOT.File=/logs/root.log
log4j.appender.ROOT.layout=org.apache.log4j.PatternLayout
log4j.appender.ROOT.layout.ConversionPattern=%d{ABSOLUTE} [%t] %-5p %c - %m%n
And the log files was nicely rolling every minute and compressing the data.
Also the mvn build was working fine (excepted for one test that was not passing
before anyway).
I did not create a Unit test for that though. Point me in the right direction
if you need one, and I'll find some time to create it.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43867] NOPLoggerRepository error during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=43867 --- Comment #56 from Gili <[EMAIL PROTECTED]> 2008-08-06 09:57:45 PST --- Dan, Are you referring to "If the underlying field is static, the class that declared the field is initialized if it has not already been initialized."? That only makes sense if Tomcat un-initializes the class somehow in the first place, but it isn't clear to me that it's doing this from your description... If it *is* then wouldn't the following technique fix the problem? 1) Null-out all references first 2) De-initializes classes second a opposed to intermixing the two phases. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43867] NOPLoggerRepository error during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=43867 --- Comment #57 from Dan Armbrust <[EMAIL PROTECTED]> 2008-08-06 11:51:44 PST --- Maybe, I don't know if that is possible or not. I don't know the reflection API's well enough. Perhaps you can pursue it with the folks on the Tomcat side: https://issues.apache.org/bugzilla/show_bug.cgi?id=41939 >From the log4j side, I still like the idea of detecting when tomcat caused the problem during a shutdown sequence, and logging the error as a much lower level message. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43867] NOPLoggerRepository error during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=43867 --- Comment #58 from Aaron Digulla <[EMAIL PROTECTED]> 2008-08-06 12:24:29 PST --- Re: Field.get(Object) Some background info on reflection and static code in a class. If you use reflection to access the static data of a class (which Tomcat has to do to clear static references so it can GC the webapp), then calling Field.get() will initialize a class if a) it hasn't been initialized, yet, b) if it has been initialized by a different classloader instead of the current one or c) when the class itself has been GC'd (not with Sun VM with default GC options but you can activate that). There are a lot of spurious problems lurking around this "feature"; I once used it to execute code while the Groovy compiler worked on my class file. It wasn't nice. So what can happen is that you need a class for something (i.e. someone imports it) but you don't actually use it. In this case, the classloader will have loaded the class but it won't be initialized. That's a standard optimization to make Java boot faster. Then, you shutdown. At that stage, Tomcat will look through all loaded classes (instead of those which are initialized) and call Field.get(). And that triggers the bug. Tomcat can't solve this, because there is no way to ask the VM if a class is initialized or not. The only solution for this kind of bug is not to use *any* static fields in code which will be deployed to Tomcat. Especially the Loggers of log4j must not be static ... and here we run into trouble because we have to mutually exclusive design goals. But maybe we can hack our way out of this. Solution 1 would be to install a listener which deinitializes log4j in such a way that any getLogger() call would return null or a NOPLogger or something. Solution 2 would be to create a private final static field which Tomcat will eventually clear. If that field is cleared (and only Tomcat can do that since it's private), you know that you're in the Tomcat shutdown cycle (instead of some misconfiguration error) and you could ignore attempts to log anything instead of throwing an error. Solution 1 would depend a bit on Tomcat but it would be reusable for other app servers. Solution 2 would be independent of the appserver; any appserver who clears static fields would just work. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43867] NOPLoggerRepository error during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=43867 --- Comment #59 from Gili <[EMAIL PROTECTED]> 2008-08-06 13:00:44 PST --- Aaron, Thanks for clarifying further how this bug may occur. Okay, so I'm fine with omitting the error message but only during the Tomcat shutdown cycle. 1) How are you going to reactivate the error message once the clearReferences method is complete? 2) Can we safely assume that no other webapp will use log4j while it is being shut down? I suspect the answer to both the above questions is that Tomcat uses a different class-loader per Webapp so Log4j will never get shared between them. So once log4j is shut down it should, in theory, never come back to life. BTW: Why does Tomcat need to null out the references if the class-loader is being unloaded (hence all the classes inside it are being unloaded anyway)? Is it reusing the same class-loader if a webapp is reloaded? In such a case I think this fix isn't so clear-cut. We need to ensure that log4j doesn't end up in a corrupt state once the shutdown process is complete. How can we guarantee this? -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43867] NOPLoggerRepository error during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=43867 --- Comment #60 from Aaron Digulla <[EMAIL PROTECTED]> 2008-08-06 13:37:47 PST --- > 1) No. > 2) Only when log4j is in WEB-INF/lib. If you put it into common/lib, one log4j instance is shared by all webapps and Tomcat itself. Unloading a classloader doesn't destroy the objects it created. As long as the objects live (and if they are static, they live forever ... or until someone nulls the reference), they will keep a reference to their class. So the classes can only be GC'd after all static references have been nulled. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 43867] NOPLoggerRepository error during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=43867 --- Comment #61 from Gili <[EMAIL PROTECTED]> 2008-08-06 14:11:40 PST --- That doesn't sound right to me. As far as I remember, static fields are bound at the ClassLoader level (they do not span them). http://forums.sun.com/thread.jspa?forumID=7&threadID=621392 says the same but I couldn't find a reference to this in the Java Language Specification (to be fair, I didn't look too deep). -- 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: [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
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). Paul - 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]
DO NOT REPLY [Bug 43867] NOPLoggerRepository error during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=43867 --- Comment #62 from Curt Arnold <[EMAIL PROTECTED]> 2008-08-06 21:57:43 PST --- >From comment #58 >But maybe we can hack our way out of this. Solution 1 would be to install a >listener which deinitializes log4j in such a way that any getLogger() call >would return null or a NOPLogger or something. >Solution 2 would be to create a private final static field which Tomcat will >eventually clear. If that field is cleared (and only Tomcat can do that since >it's private), you know that you're in the Tomcat shutdown cycle (instead of >some misconfiguration error) and you could ignore attempts to log anything >instead of throwing an error. log4j is already doing both of these things. It checks a private static field that should never be null through normal language mechanism for null and if it detects that it returns a NOPLogger instance. The complaint is that it emits a warning when it does so. If we knew that anytime that it encountered this scenario it was running in Tomcat and in clearReferences, we could just remove the warning or lower it to a debug severity. However, we can't say for certain that that is the only time it happens, we just know it is one place it happens. The last suggestion was to detect if it is in this one place that we know it happens and where we think the fallback behavior doesn't mask a bigger error and in that one scenario to reduce the severity of the message. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
