Bill,
Your description of the way the JRUN server is behaving is correct.
This is not an error with the server, but an feature of the server - and in
fact the product of one of the key benefits of servlets over traditional
CGI.
My understanding of a java web server may help you (sorry about the
woffle!):
When a servlet is first loaded (either at server start-up or first servlet
request) the server creates a SINGLE instance of that servlet class. The
object then persists on the server and is used to handle each request to
that servlet. (i.e there is generally only ever one single instance of a
servlet during the entire life-cycle of the server). For each request a new
thread is created by the servlet which handles the service methods (incl.
doGet() setc). The benefits of this are:
- no over-head for servlet object creation once it has been loaded
- smaller memory foorprint
There is a further optimisation which determines whether a servlet is
dynamically reloaded when it changes. IF the servlet is in the servers
classpath it will not be reloaded if the servlet class changes UNLESS the
server is restarted. (This removes the need for the server to constantly
check for updated versions of a servlet every time its service methods are
called).
However, there is a neat trick which allows you to place a servlet in the
(default) servlets directory (root/servlets/), and will cause the servlet to
be reloaded if its time-stamp has changed. (This feature is there for
developers). However, the servlets support classes are not checked by the
server for changes. Instead, the new support classes will only be updated
IF the calling servlet's time stamp is changed and the servlet is re-laoded
-
Therefore the answer to your question is:
Place all your servlets/support classes in the servlets directory, and
recompile the servlet if:
- the servlet changes
- the servlet's support classes change
An interesting point to note here is that if you have two servlets which
call the same support class, and you change the support class and only
compile (update) one of the servlets - then the servlet that was not
re-compiled will still use the old version of the support class.
Hope this helps.
Andy Phelps
-----Original Message-----
From: Shelton, William D [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 03, 2000 5:04 PM
To: JRun List (E-mail) (E-mail)
Subject: Object Caching Problem
Hi List:
I'm new to JRun and somewhat new to Java, so please bear with me.
Symptom:
When I make changes to a class in a package, those changes are not reflected
in the calling servlet or JSP page UNLESS I restart the JRun Server. In
fact, I get a java.lang.NoSuchMethodError
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* Simplified Package Code: */
package mystuff;
public class Person{
protected String firstName = null;
Person(){}
public void setFirstName( String fName ){
this.firstName = fName;
}
public String getFirstName(){ return this.firstName; }
} //end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The above simple code works fine when I call it from a servlet or JSP page
like so:
import mystuff.*;
import other.packages.*;
// snip ...
Person p = new Person();
p.setFirstName( "James" );
out.println( p.getFirstName() );
...
However, if I update this class to ALSO include:
protected String lastName = null;
public void setLastName( String lName ){
this.lastName = lName;
}
public String getLastName(){ return this.lastName }
...
Then when I invoke the servlet/JSP using :
Person p = new Person();
p.setFirstName( "James" );
p.setLastName ( "Kirk" );
out.println( p.getFirstName() + " " );
out.println( p.getLastName() );
...
the servlet throws a java.lang.NoSuchMethodError ...
If I restart the server, it works fine. It seems like JRun is caching the
classes in the package or is not refreshing the package.
Am I missing something obvious? Or is this a problem with a workaround?
Thanks in advance!
Bill
----------------------------------------------------------------------------
--
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe:
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe'
in the body.
------------------------------------------------------------------------------
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the
body.
