On Tue, 7 Aug 2001, Pier P. Fumagalli wrote:
> Holscher, David M at [EMAIL PROTECTED] wrote:
> >
> >> Correct, that's why it's not advisable to put it there. $CATALINA_HOME/lib
> >> is there just because sometimes you want to have libraries accessible by
> >> all your web applications WITHOUT putting them in $JAVA_HOME/jre/lib/ext.
> >
> > Yes, there are lots of things that are not advisable. I'm just saying that
> > having a way to extend the places where I look for jar files for a web-app
> > is no worse than existence of the $CATALINA_HOME/lib.
>
> I tend to disagree with you. If you consider the fact that everything under
> $JAVA_HOME/jre/lib/ext is considered "trusted" code by the VM when you
> install a SecurityManager, while code in $CATALINA_HOME/lib is not.
>
> $CATALINA_HOME/lib is there for a reason...
>
> >> Yes, but at this point I don't quite get WHY you have to have a JAR file
> >> specifically tied to a single Web Application in a directory != from your
> >> WEB-INF/lib... It there a solid explanation on why you need this behavior?
> >>
> > We have a set of jar files used by several programs which are not web
> > applications. We have a single web app which uses some of the jar files. It
> > does not make sense for the programs that are not web applications to use
> > jar files in the WEB-INF/lib directory nor does it make sense for the web
> > application to use files outside that directory. So when we build a
> > production release we make sure we have copies of the jar files in the right
> > places. However, in development when I make a change to a source file there
> > is much less pain involved if I don't have to make sure to copy the
> > resulting change to the jar file into all of the places it is needed. It is
> > simply easier to point the applications that need it to the central
> > location. Please don't answer that I should have the build script make extra
> > copies of the jar files (which will cause configuration management issues)
> > and please don't answer that the central location be the WEB-INF/lib
> > directory because most of our developers don't see that directory. I simply
> > want to know if it is possible to extend the library path for a web
> > application. At this point, I'm sure the answer is no.
>
> Well, the answer IS of course "no"... :) If you imply such a configuration
> mechanism (like specify a "classpath" for every web-application) there might
> be issues from when you move stuff around (like, from your classpath, to
> WEB-INF/lib), especially in terms of security and class loading issues.
> I believe that it can be easily solved by putting down some symlinks in your
> WEB-INF/lib, so that when you jar up the final "release" you don't even care
> what you need to copy over or not...
>
> Pier
>
>
I find that a "deploy" target in my build.xml file, which assembles the
web app in Tomcat's webapps directory (including copying JARs that are
needed) solves this kind of pain for me.
You're absolutely right that the author of a non-web JAR that you're using
shouldn't be responsible for "pushing" JAR files to wherever they are
being used -- it should be the responsibility of the user of that JAR to
"pull" as needed. Ant's <copy> task is smart enough to skip the copying
if the JAR file didn't change, so it's still pretty fast.
Now, my webapp development loop goes like this:
* Edit
* "ant compile"
* Fix compiler errors and loop back
* "ant deploy"
* Restart the webapp in Tomcat (manually or automatically)
* Test
And I never have to worry about getting the most recent JAR files -- the
deploy target took care of that for me as it was copying all my stuff into
the webapps directory.
It's even easy to parameterize build.xml so that developers can pick and
choose which version of dependent JARs they want, or use defaults. The
process of building Tomcat itself (with lots of external dependencies) has
convinced me that it's scalable to larger projects as well.
One final benefit -- creating the production distribution is now just a
matter of JARing up the deployed webapp directory into a WAR file, since
you've been developing all along in the same directory structure that
you're going to deploy.
Craig
