Re: [Q] when to share jars

2005-06-15 Thread teknokrat

delbd wrote:

Then put those libs in WEB-INF/lib too

Le Mardi 14 Juin 2005 14:31, teknokrat a écrit :


Charl Gerber wrote:


When do you share jars (struts, log4j, jstl, etc) for
webapps in the common/lib directory and when does each
app need its own copy of the jars?

Log4j we've found by trail and error is better to have
a jar per webapp, as the loggers seems to overwrite
each other, but which commonly used jars (struts,
jstl) can be shared?

Thanks

Charl


What if you have libraries in shared/lib that use log4j?
If you place log4j in WEB-INF/lib and shared/lib you get errors.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





And if we need to fix a problem in a shared library, redeploy all our 
webapps?? I don't think so



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-15 Thread Larry Meadors
How many web apps do you have? 

Put the jar in shared, and you get to restart them all anyway...on
each shared jar update.

I am sure your users will love that. ;-)

Larry


On 6/15/05, teknokrat [EMAIL PROTECTED] wrote:
 delbd wrote:
  Then put those libs in WEB-INF/lib too
 And if we need to fix a problem in a shared library, redeploy all our
 webapps?? I don't think so

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [Q] when to share jars

2005-06-14 Thread Dale, Matt

They need to be in common/lib when they need to be accessed by tomcat itself as 
well as the webapps. shared/lib would just be the webapps. I don't know about 
struts and jstl but you'd more than likely need a log4j in each webapp to get 
seperate webapp logging.

Ta
Matt

-Original Message-
From: Charl Gerber [mailto:[EMAIL PROTECTED]
Sent: 14 June 2005 10:57
To: tomcat-user@jakarta.apache.org
Subject: [Q] when to share jars


When do you share jars (struts, log4j, jstl, etc) for
webapps in the common/lib directory and when does each
app need its own copy of the jars?

Log4j we've found by trail and error is better to have
a jar per webapp, as the loggers seems to overwrite
each other, but which commonly used jars (struts,
jstl) can be shared?

Thanks

Charl


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [Q] when to share jars

2005-06-14 Thread Charl Gerber
yep, shared/lib.

I suspect struts also needs to be in every webapp, but
its gets tricky when you consider all the jars struts
require, eg commons-related stuff.


--- Dale, Matt [EMAIL PROTECTED] wrote:

 
 They need to be in common/lib when they need to be
 accessed by tomcat itself as well as the webapps.
 shared/lib would just be the webapps. I don't know
 about struts and jstl but you'd more than likely
 need a log4j in each webapp to get seperate webapp
 logging.
 
 Ta
 Matt
 
 -Original Message-
 From: Charl Gerber [mailto:[EMAIL PROTECTED]
 Sent: 14 June 2005 10:57
 To: tomcat-user@jakarta.apache.org
 Subject: [Q] when to share jars
 
 
 When do you share jars (struts, log4j, jstl, etc)
 for
 webapps in the common/lib directory and when does
 each
 app need its own copy of the jars?
 
 Log4j we've found by trail and error is better to
 have
 a jar per webapp, as the loggers seems to overwrite
 each other, but which commonly used jars (struts,
 jstl) can be shared?
 
 Thanks
 
 Charl
 
 

-
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 

-
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread Tim Funk

Never. I share jars. I wish I hadn't.

When you upgrade JSTL, struts, etc - all get the upgrade for free - but that 
means ultra stable apps which haven't been touched in years may magically 
break.


[Exception - log4j ... I like have a common/lib log4j]

-Tim

Charl Gerber wrote:


When do you share jars (struts, log4j, jstl, etc) for
webapps in the common/lib directory and when does each
app need its own copy of the jars?

Log4j we've found by trail and error is better to have
a jar per webapp, as the loggers seems to overwrite
each other, but which commonly used jars (struts,
jstl) can be shared?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread Charl Gerber
If you share log4j, wouldn't it mean that if two
web-apps both use eg com.foo.Bar, they cannot be
configured to log to different logfiles and that the
com.foo.Bar logger (with appenders) is shared between
webapps?



--- Tim Funk [EMAIL PROTECTED] wrote:

 Never. I share jars. I wish I hadn't.
 
 When you upgrade JSTL, struts, etc - all get the
 upgrade for free - but that 
 means ultra stable apps which haven't been touched
 in years may magically 
 break.
 
 [Exception - log4j ... I like have a common/lib
 log4j]
 
 -Tim
 
 Charl Gerber wrote:
 
  When do you share jars (struts, log4j, jstl, etc)
 for
  webapps in the common/lib directory and when does
 each
  app need its own copy of the jars?
  
  Log4j we've found by trail and error is better to
 have
  a jar per webapp, as the loggers seems to
 overwrite
  each other, but which commonly used jars (struts,
  jstl) can be shared?
  
 

-
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread Tim Funk
I think so. But IIRC, if you have a log4j in common/lib and WEB-INF/lib - the 
WEB-INF/lib will be used for that webapp. So you can place logging in a 
different file for that webapp and class.



-Tim

Charl Gerber wrote:


If you share log4j, wouldn't it mean that if two
web-apps both use eg com.foo.Bar, they cannot be
configured to log to different logfiles and that the
com.foo.Bar logger (with appenders) is shared between
webapps?



--- Tim Funk [EMAIL PROTECTED] wrote:



Never. I share jars. I wish I hadn't.

When you upgrade JSTL, struts, etc - all get the
upgrade for free - but that 
means ultra stable apps which haven't been touched
in years may magically 
break.


[Exception - log4j ... I like have a common/lib
log4j]

-Tim

Charl Gerber wrote:



When do you share jars (struts, log4j, jstl, etc)


for


webapps in the common/lib directory and when does


each


app need its own copy of the jars?

Log4j we've found by trail and error is better to


have


a jar per webapp, as the loggers seems to


overwrite


each other, but which commonly used jars (struts,
jstl) can be shared?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread delbd
The best place to search for this info is in the library website. You found 
the problem of log4j by trail / error? if you had read the log4j doc, it's 
written explicitly, do not put log4j in the shared lib of your container or 
you won't be able to have a different config per webapp.

For struts, it's written in doc you can't put 2 different mappings for the 
struts servlet, so it would also behave badly when put as shared library.

But what you can do is put some libraries struts depends on in shared/lib and 
struts itself in each webapp.

As a rule of thumb, ask your self if the library you are using requires any 
configuration or permanent state. If it does, ask yourself if you can afford 
this configuration to be shared by all web applications. If any of the 
answers is no, then you can't put them in shared/lib

Le Mardi 14 Juin 2005 11:57, Charl Gerber a écrit :
 When do you share jars (struts, log4j, jstl, etc) for
 webapps in the common/lib directory and when does each
 app need its own copy of the jars?

 Log4j we've found by trail and error is better to have
 a jar per webapp, as the loggers seems to overwrite
 each other, but which commonly used jars (struts,
 jstl) can be shared?

 Thanks

 Charl


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-- 
David Delbecq
Royal Meteorological Institute of Belgium

-
Is there life after /sbin/halt -p?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread Nikola Milutinovic

Tim Funk wrote:


Never. I share jars. I wish I hadn't.

When you upgrade JSTL, struts, etc - all get the upgrade for free - 
but that means ultra stable apps which haven't been touched in years 
may magically break.



You're absolutely right Tim. If it works, don't fix it. And there is 
nothing worse than fixing (and breaking) something you never intended to 
touch, in the forst place. JPackage project is a valiant effort, but 
anyone who has gone through their (or any other) RPM dependency hell 
knows that stability is hard to achieve and even harder to preserve.


You might lean on JPackage, but you'll still be unable to prevent 
upgrade from breaking stuff. Of course, you can require an exact version 
of JSTL, Struts,..., but that is just like saying don't touch anything.


Since there is nothing in the J2EE contract that would provide some sort 
of library versioning control, the only thing you can do is package 
JARs with each web-app. That, unfortunately, bloats the WAR, but there 
is no other way to ensure stability.



[Exception - log4j ... I like have a common/lib log4j]



Didn't someone complain on loggers overwriting each other? Of course, it 
might be a case of misuse.


Nix.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread Larry Meadors
Amen brother!

Sharing jars between web apps is just a Bad Idea (tm). 

Disk is cheap, and so is the time required to copy a jar. 

...unless you are an ISP with 1000+ web apps running on a sinlge box,
then it *might* be OK, but even then, I would stop and think very
carefully before doing it.

Larry

On 6/14/05, Tim Funk [EMAIL PROTECTED] wrote:
 Never. I share jars. I wish I hadn't.
 
 When you upgrade JSTL, struts, etc - all get the upgrade for free - but that
 means ultra stable apps which haven't been touched in years may magically
 break.
 
 [Exception - log4j ... I like have a common/lib log4j]
 
 -Tim
 
 Charl Gerber wrote:
 
  When do you share jars (struts, log4j, jstl, etc) for
  webapps in the common/lib directory and when does each
  app need its own copy of the jars?
 
  Log4j we've found by trail and error is better to have
  a jar per webapp, as the loggers seems to overwrite
  each other, but which commonly used jars (struts,
  jstl) can be shared?
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread teknokrat

Charl Gerber wrote:

When do you share jars (struts, log4j, jstl, etc) for
webapps in the common/lib directory and when does each
app need its own copy of the jars?

Log4j we've found by trail and error is better to have
a jar per webapp, as the loggers seems to overwrite
each other, but which commonly used jars (struts,
jstl) can be shared?

Thanks

Charl


What if you have libraries in shared/lib that use log4j?
If you place log4j in WEB-INF/lib and shared/lib you get errors.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread delbd
Then put those libs in WEB-INF/lib too

Le Mardi 14 Juin 2005 14:31, teknokrat a écrit :
 Charl Gerber wrote:
  When do you share jars (struts, log4j, jstl, etc) for
  webapps in the common/lib directory and when does each
  app need its own copy of the jars?
 
  Log4j we've found by trail and error is better to have
  a jar per webapp, as the loggers seems to overwrite
  each other, but which commonly used jars (struts,
  jstl) can be shared?
 
  Thanks
 
  Charl

 What if you have libraries in shared/lib that use log4j?
 If you place log4j in WEB-INF/lib and shared/lib you get errors.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-- 
David Delbecq
Royal Meteorological Institute of Belgium

-
Is there life after /sbin/halt -p?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: RE: [Q] when to share jars

2005-06-14 Thread Giuseppe Briotti
 ==
 Date: Tue, 14 Jun 2005 11:43:04 +0100 (BST)
 From: Charl Gerber [EMAIL PROTECTED]
 To: Tomcat Users List tomcat-user@jakarta.apache.org
 Subject: RE: [Q] when to share jars
 ==
 
 yep, shared/lib.
 
 I suspect struts also needs to be in every webapp, but
 its gets tricky when you consider all the jars struts
 require, eg commons-related stuff.
 

mmmh, no, I don't think so. We have just one struts jar in shared/lib

G.

--

Giuseppe Briotti
[EMAIL PROTECTED]

Alme Sol, curru nitido diem qui 
promis et celas aliusque et idem 
nasceris, possis nihil urbe Roma 
visere maius.
(Orazio)





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Q] when to share jars

2005-06-14 Thread Andre Van Klaveren
Bottom line is that the only libraries you should put in shared/lib
are ones that you know are stable and won't be changing much, if at
all (can anybody really know this?).  Every application that depends
on a shared library gets impacted when you upgrade the shared library.
 If there are several development teams responsible for applications
on the server you now have to coordinate with each team to regression
test every impacted application.

It's just not worth the time and effort.  Like another poster
commented, disk is cheap so who cares if your WAR gets bigger.


-- 
Virtually,
Andre Van Klaveren
Architect III, SCP
Enterprise Transformation Services
Unisys Corporation

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]