I'm not sure about commons-logging, but log4j is definitely not share-safe.
I tried it, and in our case, ended up with messages from different webapps interleaving in "seemingly random" log files. That might have had more to do with how my developers were using log4j than the library itself, but I still ended up moving the log4j *and* commons-logging back into WEB-INF/lib. I've not had any problems sharing the Oracle class library, but if you're running a jvm 1.5 (1.4? see oracle docs) or greater, then you really should be using the ojdbc14.jar file instead of classes12.jar. And get the latest (or at least 10.2.0.4) version from the Oracle website to get any bug fixes or performance improvements. -----Original Message----- From: Joseph Morgan [mailto:joseph.mor...@ignitesales.com] Sent: Wednesday, November 04, 2009 7:50 AM To: Tomcat Users List; p...@pidster.com Subject: RE: webapps question I think you're right: http://stackoverflow.com/questions/217929/problem-with-commons-logging-l og4j-setup-in-spring-webapp-with-tomcat-6 So commons-logging is not safe in common lib area. -----Original Message----- From: Pid [mailto:p...@pidster.com] Sent: Wednesday, November 04, 2009 7:23 AM To: Tomcat Users List Subject: Re: webapps question On 04/11/2009 13:17, Joseph Morgan wrote: > Michele, > > It looks like all of the jar files you mention can safely be deployed in > Tomcat's common lib area. I'm not sure that's true of commons-logging or log4j. Someone else might have a better memory than me, but I've a feeling that they hold onto classloader references, which may cause a memory leak during redeployments. p > Another question, though, to ask yourself and your developers is, do you > really need 100 individual web apps to support the web services you > have? > > In other words, there is no requirement to have a 1 to 1 correlation > between applications and web services. > > Joe > > -----Original Message----- > From: Michele Mase' [mailto:michele.m...@gmail.com] > Sent: Wednesday, November 04, 2009 4:56 AM > To: Tomcat Users List > Subject: Re: webapps question > > Thanx 4 you answer; > ps: there are 100 webservices, not webapps > Pls, help me: I'm not a developer ... and I don't understand the > disadvantages of "static classes/fields loaded from common classloader > will > be shared among all webapps", Could you be a little more specific about > the > disadvantages? > Your suggestion is to "split" the apps into vitualhost like, context.xml > ecc..? > I use the oracle odbc thin; which problem should I have putting the jdbc > driver int the commos/lib ? > For reference, those are the jars userd in all webservices: > classes12.jar > ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar activation.jar > axis-ant.jar axis.jar commons-discovery-0.2.jar > commons-logging-1.0.4.jar > jaxrpc.jar LEGO_CONDIVISI.jar log4j-1.2.8.jar mail.jar saaj.jar > wsdl4j-1.5.1.jar xmlsec-1.4.0.jar > Michele > > On Wed, Nov 4, 2009 at 11:00 AM, Mikolaj Rydzewski<m...@ceti.pl> wrote: > >> Michele Mase' wrote: >> >>> I've 100 webapps on one single tomcat instance. >>> Every webapps has in his WEB-INF/lib the same jars >>> I've some permgen memory problems too >>> Moving all the shared libs in tomcat's root/common/lib should help me >>> reducing the perm gen memory usage? >>> Should it be a good pratics >>> >> It will solve one problem, but will cause others, difficult to trace. > E.g. >> static classes/fields loaded from common classloader will be shared > among >> all webapps. >> You should rather refactor your webapp to be able to change its 'work >> context' depending on URI/domain name. >> >> -- >> Mikolaj Rydzewski<m...@ceti.pl> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org ******************************* NOTICE ********************************* This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
