Thanx for the log4j hint! I'had only listed the libs. The most difficult thing is to explain some "ancient" developers (they wrote the webservices) that sometimes they should change the old library! I'll try to put all libraries except from commons-logging and log4j into the shared libs Michele
On Thu, Nov 5, 2009 at 8:33 PM, Jeffrey Janner <jeffrey.jan...@polydyne.com>wrote: > 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<http://stackoverflow.com/questions/217929/problem-with-commons-logging-l%0Aog4j-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 > >
