----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
on 2/2/00 12:43 PM, Rusty Wright <[EMAIL PROTECTED]> wrote:
> Is there any "rule" or preference as to whether libraries should be
> installed in the servlets directory or put in the classpath?
>
> What are the pros and cons of installing them in either place? The
> main pro that I know of is that when they're installed in the servlets
> directory they'll be reloaded when the library is updated or changed.
> Does installing them in either place make more work for the programmer
> (I'm just a lowly unix sysadmin, not a java programmer)?
>
> What about when installing libraries like cocoon or jyve or ones from
> Sun, for example? I would think that they could go in the classpath
> but is there any down side to that?
>
> I looked all over the jserv web page but couldn't find any discussion
> of this.
Hello Rusty,
Think about it this way:
You seem to understand the difference between the two, one has class
reloading when the files are changed and one doesn't. Good.
Apache JServ has to keep track of the time and date stamps of every single
class loaded through its classloader. This is done with an inner class. It
then has to periodically go through that list and hit the disk to see if the
file has changed. This is an expensive operation because it involves disk
access. If one single file has changed, it then must dump the entire
classloader and all of its objects, create a new one, serialize and
de-serialize the session objects (Apache JServ 1.1 and higher) and then
start loading everything over again. Ouch. On a fast machine with a fast
disk, you normally don't notice this to badly luckily. On a slower or loaded
machine, this is expensive.
In a production environment, you should turn off class reloading so that
this is not an issue. Just HUP the server when you want to reload classes.
In a load balanced situation, this is easy to do because you have failover
support.
So, files that you don't expect to change, like the JavaMail API and such
you should put into the system classpath. Files that you do expect to change
should go into the repo path. Another way to think about it is this...files
you have source code to, put into the repo path. Everything else, put into
the system classpath. You can't (legally) change the JavaMail API files, so
you don't need to keep track of their modification times. ;-)
Now, one thing I should look into and verify is if we track the class
modification times within a .jar file or if we just look at the .jar file
itself. That would be a nice optimization we could make if we are looking
within the .jar file.
I hope that helps explain things.
-jon
--
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]