so what is the best option....
where should you place database jar's, ibm queue jar's etc..., surely you
would not copy them into your applications web-inf area? additionaly I would
not want them in the tomcat classpath?
what is the prefered solution ?
I need to consider that more than the web server mayuse the jar files so I
do not want to copy them into the web server area, additionaly I don't like
the idea of changing the supplied tomcat.sh or the global CLASSPATH
environment.
Can you not add .jars to the application configuration ?
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 5:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Moving /WEB-INF/lib or adding to it in TC 4.0
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
___________________________________________________
Email Disclaimer
This communication is for the attention of the
named recipient only and should not be passed
on to any other person. Information relating to
any company or security, is for information
purposes only and should not be interpreted as
a solicitation or offer to buy or sell any security.
The information on which this communication is based
has been obtained from sources we believe to be reliable,
but we do not guarantee its accuracy or completeness.
All expressions of opinion are subject to change
without notice. All e-mail messages, and associated attachments,
are subject to interception and monitoring for lawful business purposes.
___________________________________________________
