If you're using Java 1.2+ you should be able to put these sorts of shared
jars in the $JAVA_HOME/jre/lib/ext directory.
It works for me.
> 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.
> ___________________________________________________
>
--
D. Jay Newman ! // The worst possible legal hashCode
[EMAIL PROTECTED] ! public int hashCode() { return 42;}
http://www.sprucegrove.com/~jay/ ! -- _Effective Java_
