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: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org

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: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org

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. 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? course, it
might be a case of misuse.

Nix.

To unsubscribe, e-mail: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org

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 K, but even then, I would stop and think very
carefully before doing it.

Larry

6/14/05, Tim Funk <funkman (AT) joedog (DOT) orgwrote:
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: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org

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: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org

delbd wrote:
Then put those libs in WEB-INF/lib too

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

>>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: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
>>For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org

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: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org

How many web apps do you have?

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

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

Larry

6/15/05, teknokrat <teknokrat (AT) yahoo (DOT) comwrote:
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: tomcat-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tomcat-user-help (AT) jakarta (DOT) apache.org