No probs - hope that helped. Here are some more thoughts... Please elaborate on why you want to avoid having n copies of a jar version in different contexts. In theory, it is a good principle, but I will argue that that principle applies well to source code and other situations, but not necessarily in this deployment context.
I think you need to question your motives for this quest... - is there a driving business or technical need? - is it a purist drive? The "multiple copies" issue matters only with larger memory footprints. Take a look at the size of your classes - my guess is your core jars are less than 1 Meg each, and probably close to 250K(?). Hardly cause for concern in either case, unless you are deploying many many apps on this one server. Additionally, - links do not work well in source control tools - you could have the deployment script (ant) create the link for you upon deployment; at least then the app's dependency on the "external" jar is documented in the automated deployment tool, but what is it to do when the jar to link to does not exist? - how do you guarantee a reproducible build with that approach? - and a last "perhaps" - there might exist optimizations under the hood to mitigate the multiple copies of classes It is best to have all dependencies possible under source control with the app. source + tools = product. Commonly, main tools are assumed to exist such as the OS, the compiler, ant, checkstyle, etc., but in a rigorous engineering environment they will be under source control too as they are dependencies of the product. However, external jars for APIs, libs, etc. (e.g. log4j, junit, struts, custom libs) are not assumed and the version used is under control of the source tree for the product. Under your proposal, you still have different versions of core libs "haunting the server" - they are just in one place now. I think you have just moved the problem to a different location. Plus, you may not ever accurately know which apps are using a particular jar. And I think you have a more complex situation of guaranteeing the right version is in use for each product! Using the source control tool to handle the product dependencies is still the best approach. <tangent> I have only been talking from a webapp/war level. Remember, there are two "best practice" levels to place jars: WAR level and EAR level. If multiple webapps are packaged into an ear and all rely on the same jar version, it may be appropriate to share the jar at the ear level. But, my other arguments apply here with the "one app needs the newer version, all must upgrade" issue. Buyer beware... </tangent> Here is the scenario to think from: New deployment/runtime server, new build server, fresh install of Tomcat. What is the most foolproof method to get an app up and running? 1) Sync a workspace to a label or head revision of the app version's source tree. 2) Type "ant deploy". This is very easy and a guaranteed reproducible build with dependencies under source control of the app. This has an assumption: the build and deployment servers are already configured with tools to the appropriate level that you are source controlling dependencies to (e.g. Tomcat, Java, Ant) since they are not under source control. Messing around with jars, etc. - assuming they are on the server - is not error-proof, and invites pain! Architecture, design, and coding are a lot more fun than diagnosing runtime problems that are attributed to deployment problems... Make the deployment process clean, simple, and straightforward as you can. My opinion is that your ideas, while admirable in their quest, are interjecting complexity at the risk of creating runtime problems attributed to deployment problems. <well, I ranted longer than expected...hope that helps your thoughts and progress!> > -----Original Message----- > From: Johannes Fiala [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 23, 2003 5:06 AM > To: Tomcat Users List > Subject: RE: Reloading shared/lib JAR files? > > > 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]
