webapps question

[Michele Mase']

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?
Michele

[Mikolaj Rydzewski-2]

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 <miki@...>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michele Mase']

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 <miki@...> 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 <miki@...>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Ognjen Blagojevic-3]

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?

No.

Search the mailing list archives. All your questions are answered in
last couple of days.

Regards,
Ognjen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mikolaj Rydzewski-2]

Michele Mase' wrote:
> 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?
>  
It might break your webapps/services in many ways, diffucult to trace.
However, there's a chance everything will work. If you're not a
developer better do not change anything.

--
Mikolaj Rydzewski <miki@...>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joseph Morgan-2]

Michele,

It looks like all of the jar files you mention can safely be deployed in
Tomcat's common lib area.

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.mase@...]
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 <miki@...> 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 <miki@...>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Pid Ster]

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.mase@...]
> 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<miki@...>  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<miki@...>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joseph Morgan-2]

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:pid@...]
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.mase@...]
> 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<miki@...>
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<miki@...>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mikolaj Rydzewski-2]

Joseph Morgan wrote:
> So commons-logging is not safe in common lib area.
>  
I think, that OP's environment is a production one. So redeployment is
not a problem. I mean it's not common to redeploy webapps often in
production environment.
But depending on design of webapps, classes loaded from shared
classloader might be a problem or not.

--
Mikolaj Rydzewski <miki@...>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michele Mase']

There are 87 webservices, initially served by 2 tomcat;
The idea was, put (if possible) most of the libs in the common area and
eventually split the whole work into 4 tomcats each one serving 20
webservices.
No hope about different contexts :(
Ok for the commons-logging/log4j part
I don't know if putting the oracle jdbc thin driver into common area could
be an issue (all webservices are using the same db)
Michele


On Wed, Nov 4, 2009 at 2:17 PM, Joseph Morgan <joseph.morgan@...
> wrote:

> Michele,
>
> It looks like all of the jar files you mention can safely be deployed in
> Tomcat's common lib area.
>
> 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.mase@...]
> 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 <miki@...> 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 <miki@...>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Jeffrey Janner]

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.morgan@...]
Sent: Wednesday, November 04, 2009 7:50 AM
To: Tomcat Users List; pid@...
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:pid@...]
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.mase@...]
> 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<miki@...>
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<miki@...>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



*******************************  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-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michele Mase']

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.Janner@...>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.morgan@...]
> Sent: Wednesday, November 04, 2009 7:50 AM
> To: Tomcat Users List; pid@...
> 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:pid@...]
> 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.mase@...]
> > 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<miki@...>
> 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<miki@...>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> *******************************  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-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Jeffrey Janner]

Michele -
I just double-checked the Oracle website
(http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jd
bc_10201.html) and confirmed that the classes12.jar file is meant for
use with JDK 1.2 & 1.3.  If you're using anything later, you should be
using the ojdbc14.jar file.  IF your developers don't want to up-version
the library, then you can just swap out for the ojdbc14.jar file from
the same place you got the classes12.jar file.
In the meantime, go to the above and familiarize yourself with the
README.  It's a helpful doc.
Jeff

-----Original Message-----
From: Michele Mase' [mailto:michele.mase@...]
Sent: Thursday, November 05, 2009 3:26 PM
To: Tomcat Users List
Subject: Re: webapps question

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.Janner@...>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.morgan@...]
> Sent: Wednesday, November 04, 2009 7:50 AM
> To: Tomcat Users List; pid@...
> 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/quest
ions/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:pid@...]
> 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.mase@...]
> > 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<miki@...>
> 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<miki@...>
> >>
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
---------------------------------------------------------------------

> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> *******************************  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-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

*******************************  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-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeffrey Janner]

Ok, the README on the web-page below isn't very helpful (just a
fixed-bugs list), but search the site.  There is a good one.

-----Original Message-----
From: Jeffrey Janner [mailto:Jeffrey.Janner@...]
Sent: Friday, November 06, 2009 8:57 AM
To: Tomcat Users List
Subject: RE: webapps question

Michele -
I just double-checked the Oracle website
(http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jd
bc_10201.html) and confirmed that the classes12.jar file is meant for
use with JDK 1.2 & 1.3.  If you're using anything later, you should be
using the ojdbc14.jar file.  IF your developers don't want to up-version
the library, then you can just swap out for the ojdbc14.jar file from
the same place you got the classes12.jar file.
In the meantime, go to the above and familiarize yourself with the
README.  It's a helpful doc.
Jeff

-----Original Message-----
From: Michele Mase' [mailto:michele.mase@...]
Sent: Thursday, November 05, 2009 3:26 PM
To: Tomcat Users List
Subject: Re: webapps question

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.Janner@...>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.morgan@...]
> Sent: Wednesday, November 04, 2009 7:50 AM
> To: Tomcat Users List; pid@...
> 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/quest
ions/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:pid@...]
> 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.mase@...]
> > 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<miki@...>
> 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<miki@...>
> >>
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
---------------------------------------------------------------------

> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> *******************************  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-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

*******************************  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-unsubscribe@...
For additional commands, e-mail: users-help@...



*******************************  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-unsubscribe@...
For additional commands, e-mail: users-help@...