Thanks Konstantin: I appreciate all the great information. I'm going to look into log4j while I'm involved with logging. Hopefully by the end there will be a clear winner between java.util.logging, JULI, and log4j, based on our needs. Much Thanks.
TC Konstantin Kolinko wrote: > > 2011/6/24 throwsCode <donmillho...@yahoo.com>: >> >> Hi Konstantin: >> >> I added the following argument to the Apache Tomcat Server Run >> Configuration: >> >> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager >> >> It worked just as you suggested it would; however, it requires the >> argument >> be placed in the VM arguments section. I have many small clients that on >> occassion share VMs with other Tomcat Servers. Is there a way to do the >> same without the Runtime Argument? >> > > Embedding? > > I am afraid that there is no other way. > > This property configures java.util.logging implementation used by VM. > > IIRC in java.util.logging there exists a method that allows to reset > logging configuration, but I think it only allows to reconfigure > handlers, and does not support replacing LogManager at runtime. > > You can look into JRE sources to see at what time the value of > "java.util.logging.manager" property is being read. > > > (*) You may have better luck by configuring Tomcat to use log4j (see > relevant section in our logging.html). With log4j you can go without > ClassLoaderLogManager and without logging.properties, but there is one > caveat: > - Tomcat (using commons-logging) and webapps that use > commons-logging will detect presence of log4j and use it instead of > java.util.logging > - Any web-applications that use java.util.logging will try to use > default LogManager implementation, and will suffer from PermGen memory > leaks during redeployments and restarts. Because default LogManager > from JRE will keep their classes in memory. > > The (*) is theory. I have not tested it in practice. > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- View this message in context: http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31916749.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
