Hi Jeff,
Thank you very much for the detailed outline.
The reason why I wanted to use a central library was that I wanted to
prevent different versions of my core libs haunting the contexts of the
Tomcat server. So you're suggested solution would be to leave it up to
the separate contexts to update and use the newer lib files.
The only drawback of this "terms of use" is, that you have one component n
times installed across the various contexts of the Tomcat. This was what I
wanted to avoid....
So to use both ideas, what about the following:
*) central repository of all versions of all helper jar files
/{$tomcat_home}/repository/v1.jar
/{$tomcat_home}/repository/v2.jar
*) each application context picks the version it likes to use
/{$tomcat_home}/webapps/myapp/WEB-INF/lib/<link to v1.jar>
/{$tomcat_home}/webapps/myapp2/WEB-INF/lib/<link to v2.jar>
Do you think the approach outlined above makes sense?
I think this would reduce the "scattered" library version troubles and it
would even be possible to search all the contexts to find out which
versions are used.
Thx for your feedback
Johannes
"Jeff Jensen" <[EMAIL PROTECTED]>
22.03.2003 16:44
Please respond to
"Tomcat Users List" <[EMAIL PROTECTED]>
To
"'Tomcat Users List'" <[EMAIL PROTECTED]>
cc
Subject
RE: Reloading shared/lib JAR files?
Also, from a release management standpoint, the risk is the dependency of
all the apps on the specific versions of the jars in shared/lib. Meaning,
if one app needs a newer version of a shared component placed in
shared/lib,
then all are forced to upgrade as well. Timing on upgrading the other
apps
is not usually so helpful, particularly when needing even a small coding
change!
It is typically better to use the source control tool to integrate
specific
versions of shared components into its own codeline - so the codeline is
complete without external dependencies (reproducible builds from the
source
tree). If it is a 3rd party component, check-in the distributables and
integrate/merge the right versions of them into your different product
codelines. If it is your own component, do the same - check-in the
distributables. For deployment, as part of the normal
build/package/deploy
process, place the shared components in WEB-INF/lib so each app can have
its
own version.
As Tim says, this would "rethink the design" and solve the problem by not
having anything in shared/lib. At the same time, eliminating a potential
cross-application dependency problem.
Disclaimer - there may be something in your environment that forces you to
use shared/lib (or possibly never even have an upgrade problem), whether
technical (can't think of much other than large footprint jars) or
"political" ;-)
Your mileage may vary.
> -----Original Message-----
> From: Tim Funk [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 22, 2003 8:50 AM
> To: Tomcat Users List
> Subject: Re: Reloading shared/lib JAR files?
>
>
> If you redeploy jars into /shared/lib - they will not be
> reloaded on a
> webapp reload and there is no way to reload them(except a
> stop/start of
> tomcat). But jars/classes in WEB-INF/ can be reloaded.
>
> If you have jars in shared/lib that need reloaded when an webapp is
> reloaded - you might need to rethink the design of those shared libs.
>
> -Tim
>
> Johannes Fiala wrote:
> > Hi there,
> >
> > I know it is possible to reload a web-application using the
> manager app
> > (especially the JAR-files in WEB-INF/lib).
> > Is it possible to also include the shared/lib directory?
> >
> > We have some helper JARs, which are used by four web
> contexts, so I'd
> > prefer to put them into /shared/lib.
> > However, if it doesn't get reloaded after an update of
> /shared/lib, I have
> > no means to perform a hot redeploy if only the JAR files change.
> >
> > thx alot
> > Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
