You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/01/03 01:36:57 UTC

classreloading and 4.x

Ok, I have this in my server.xml:

        <Context path="" docBase="scarab" reloadable="true"/>

Yet when I change a class in my WEB-INF/classes directory, it doesn't get
reloaded. Any ideas?

-jon


Re: classreloading and 4.x

Posted by Jon Stevens <jo...@latchkey.com>.
on 1/3/2001 2:09 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:

> I will look at this, using your recipie below, this afternoon.  One quick
> confirmation, though -- the classes you are changing are in WEB-INF/classes,
> right?  And not in WEB-INF/lib or $CATALINA_HOME/lib?
> 
> Craig

Correct. The classes get re-compiled into the WEB-INF/classes directory by
the build.sh script.

-jon

-- 
Honk if you love peace and quiet.



Re: classreloading and 4.x

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:

> hey craig,
>
> classreloading is still broken.
>

I will look at this, using your recipie below, this afternoon.  One quick
confirmation, though -- the classes you are changing are in WEB-INF/classes,
right?  And not in WEB-INF/lib or $CATALINA_HOME/lib?

Craig


>
> To test:
>
> #1. Check Scarab out of CVS.
> #2. cd build; ./build.sh
> #3. cd target; ./bin/catalina.sh run
> #4. <http://localhost:8080/scarab/servlet/scarab/template/Register.vm>
> #4a. click submit (no need to fill out the form)
> #5. Notice System.out.println's
> #6. Edit scarab/src/java/org/tigris/scarab/om/ScarabUser.java
>     Change one of the println's.
> #7. cd build; ./build.sh
> #8. Repeat #4 and #4a. Notice the println doesn't change.
>
> FYI, the catalina.jar is the one you sent me from last night.
>
> -jon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org


Re: classreloading and 4.x

Posted by Rolf Veen <ro...@helide.com>.
Craig R. McClanahan wrote:


> (...)
> We can certainly decide that the "$CATALINA_HOME/webapps/scarab" directory has already
> been deployed under *some* context path, and not deploy it again.  But that means you
> would not be allowed to deploy the same directory under two context paths, even if you
> wanted to -- which might be something a sysadmin wants to do under some circumstances
> (especially if you're embedded inside a J2EE server that uses JNDI contexts to provide
> customized references to JDBC data sources or EJBs).
> 
> What do folks think?  If we're going to change this historical behavior of Tomcat,
> doing so at a major version number change is *much* better than doing it any other
> time.

None of the commiters has answered your question yet, so as a Tomcat 
user I have no problem with the current behavior since I only use the 
standard way ( context path = directory name ).

Thanks, Craig.
Rolf.


Re: classreloading and 4.x

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Rolf Veen wrote:

> Hi (feliz año nuevo).
>
> Craig R. McClanahan wrote:
>
> > First, your web.xml file defines the root webapp like so:
> >     <Context path="" docBase="scarab" reloadable="true">
> >         <Loader checkInterval="3"
> >          className="org.apache.catalina.loader.StandardLoader"/>
> >     </Context>
> > so Catalina initializes a nice webapp for you, including reloading support.
> >
> > Next, Catalina finds a directory named "scarab" under the "webapps" directory,
> > so it auto-deploys *another* context for the same document root, with a context
> > path of "/scarab".  By default reloadable is set to false, so this webapp has it
> > turned off.
> >
>
> Maybe a stupid question:
>

Not a stupid question at all.

>
> Isn't it possible to recognize these two contexts as being the same ?
>

The problem is in deciding what the criteria is for "same-ness".

Normally, you set up Tomcat so that the directory name (within "webapps") is the same
as the context path (minus the leading "/"), so that a directory named "scarab" would
be auto-deployed on context path "/scarab".  There is a special case for the root
webapp (context path ""), which is recognized in a directory named "ROOT" because
zero-length directory names are frowned upon by both platforms.

In the case of the example above, the <Context> entry breaks this usual convention,
because it uses a different context path than the directory name.  (And none of this
is new to 4.0 -- check the TOMCAT-USER archives for questions about "my application
was deployed twice" or "my servlet was initialized three times" and you will see what
I mean.)

We can certainly decide that the "$CATALINA_HOME/webapps/scarab" directory has already
been deployed under *some* context path, and not deploy it again.  But that means you
would not be allowed to deploy the same directory under two context paths, even if you
wanted to -- which might be something a sysadmin wants to do under some circumstances
(especially if you're embedded inside a J2EE server that uses JNDI contexts to provide
customized references to JDBC data sources or EJBs).

What do folks think?  If we're going to change this historical behavior of Tomcat,
doing so at a major version number change is *much* better than doing it any other
time.

>
> >
> > Craig
> >
>
> Rolf.
>

Craig



Re: classreloading and 4.x

Posted by Rolf Veen <ro...@helide.com>.
Hi (feliz año nuevo).

Craig R. McClanahan wrote:


> First, your web.xml file defines the root webapp like so:
>     <Context path="" docBase="scarab" reloadable="true">
>         <Loader checkInterval="3"
>          className="org.apache.catalina.loader.StandardLoader"/>
>     </Context>
> so Catalina initializes a nice webapp for you, including reloading support.
> 
> Next, Catalina finds a directory named "scarab" under the "webapps" directory,
> so it auto-deploys *another* context for the same document root, with a context
> path of "/scarab".  By default reloadable is set to false, so this webapp has it
> turned off.
> 

Maybe a stupid question:

Isn't it possible to recognize these two contexts as being the same ?

> 
> Craig
> 

Rolf.




Re: classreloading and 4.x

Posted by Jon Stevens <jo...@latchkey.com>.
on 1/3/2001 3:37 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:

> * Put the "scarab" webapp directory somewhere other than in
> $CATALINA_HOME/webapps, and set your docBase
> parameter above to an absolute path to it -- or at least
> a path that is relative to the "appBase" directory of the <Host>.

yuck. no absolute paths. I want ppl to be able to use Scarab without having
to edit properties files to get things working on their boxes.

> * Call your "scarab" directory "ROOT" instead (which is the
> name used when auto-deploying the root webapp).  Because
> it will have already been initialized by your <Context>, no
> second webapp will be created.

I don't want to screw up others ROOT directories.

> * Turn off auto-deploy support.  Hmm, there's no configuration
> setting for that just yet, so it doesn't help right now, but
> that will get fixed.

This sounds like my only solution, but isn't available yet. :-(

> * Define your webapp with context path "/scarab" instead
> of context path "".  I don't know what that would do to Turbine's
> internal request URI processing, but it should be possible.  It
> works (from the Catalina perspective) for the same reason that
> option 2 would -- it won't deploy two webapps on the same
> context path.

This doesn't work. I get that "Turbine isn't a servlet" error.


Any other ideas on solving this problem? What do others do? Is there
something I can define in my web.xml? I'm sorry, but my knowledge of web.xml
and server.xml manipulation is very limited currently.


> One other thing that bit me when testing this -- I normally have a
> CATALINA_HOME
> environment variable set.  If you follow the indicated directions
> (./bin/catalina.sh run), you will be running the copy in CATALINA_HOME, not in
> the Scarab build directory.  You might want to add a startup script that
> explicitly unsets CATALINA_HOME and then does the usual "run" or "start".

I added better documentation to the README.txt file for now.

> PS:  Thanks for the good test case!

Thanks. That is why I feel it is so important to have a working sandbox that
is easy for people to get up and running quickly with.

-jon

-- 
Honk if you love peace and quiet.


Re: classreloading and 4.x

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:

> hey craig,
>
> classreloading is still broken.
>
> To test:
>
> #1. Check Scarab out of CVS.
> #2. cd build; ./build.sh
> #3. cd target; ./bin/catalina.sh run
> #4. <http://localhost:8080/scarab/servlet/scarab/template/Register.vm>
> #4a. click submit (no need to fill out the form)
> #5. Notice System.out.println's
> #6. Edit scarab/src/java/org/tigris/scarab/om/ScarabUser.java
>     Change one of the println's.
> #7. cd build; ./build.sh
> #8. Repeat #4 and #4a. Notice the println doesn't change.
>
> FYI, the catalina.jar is the one you sent me from last night.
>

OK, I know what is going on here ...

First, your web.xml file defines the root webapp like so:
    <Context path="" docBase="scarab" reloadable="true">
        <Loader checkInterval="3"
         className="org.apache.catalina.loader.StandardLoader"/>
    </Context>
so Catalina initializes a nice webapp for you, including reloading support.

Next, Catalina finds a directory named "scarab" under the "webapps" directory,
so it auto-deploys *another* context for the same document root, with a context
path of "/scarab".  By default reloadable is set to false, so this webapp has it
turned off.

Third, you submit a request that starts with "/scarab/...".  The spec requires
"longest match wins" on the match of context paths, so it's going to pick (you
guessed it) the second webapp -- the one that does *not* have reloadable set to
true.  Ergo, no reloading.

Four possible solutions:

* Put the "scarab" webapp directory somewhere other than in
  $CATALINA_HOME/webapps, and set your docBase
  parameter above to an absolute path to it -- or at least
  a path that is relative to the "appBase" directory of the <Host>.

* Call your "scarab" directory "ROOT" instead (which is the
  name used when auto-deploying the root webapp).  Because
  it will have already been initialized by your <Context>, no
  second webapp will be created.

* Turn off auto-deploy support.  Hmm, there's no configuration
  setting for that just yet, so it doesn't help right now, but
  that will get fixed.

* Define your webapp with context path "/scarab" instead
  of context path "".  I don't know what that would do to Turbine's
  internal request URI processing, but it should be possible.  It
  works (from the Catalina perspective) for the same reason that
  option 2 would -- it won't deploy two webapps on the same
  context path.

One other thing that bit me when testing this -- I normally have a CATALINA_HOME
environment variable set.  If you follow the indicated directions
(./bin/catalina.sh run), you will be running the copy in CATALINA_HOME, not in
the Scarab build directory.  You might want to add a startup script that
explicitly unsets CATALINA_HOME and then does the usual "run" or "start".

>
> -jon
>

Craig

PS:  Thanks for the good test case!




Re: classreloading and 4.x

Posted by Jon Stevens <jo...@latchkey.com>.
hey craig,

classreloading is still broken.

To test:

#1. Check Scarab out of CVS.
#2. cd build; ./build.sh
#3. cd target; ./bin/catalina.sh run
#4. <http://localhost:8080/scarab/servlet/scarab/template/Register.vm>
#4a. click submit (no need to fill out the form)
#5. Notice System.out.println's
#6. Edit scarab/src/java/org/tigris/scarab/om/ScarabUser.java
    Change one of the println's.
#7. cd build; ./build.sh
#8. Repeat #4 and #4a. Notice the println doesn't change.

FYI, the catalina.jar is the one you sent me from last night.

-jon


Re: classreloading and 4.x

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:

> on 1/2/2001 10:28 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
> wrote:
>
> > You've got mail.
> >
> > Craig
>
> Craig, did you get my message? I tested the .jar file you sent me and it
> doesn't work. Let me know if you need me to re-send the message again.
>

If you sent it today to me personally or to TOMCAT-DEV (I'm not through all the
mailing lists I subscribe to yet), I haven't seen it ... you might want to try
sending again.

>
> thx.
>
> -jon
>

Craig


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org


Re: classreloading and 4.x

Posted by Jon Stevens <jo...@latchkey.com>.
on 1/2/2001 10:28 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:

> You've got mail.
> 
> Craig

Craig, did you get my message? I tested the .jar file you sent me and it
doesn't work. Let me know if you need me to re-send the message again.

thx.

-jon


Re: classreloading and 4.x

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:

> on 1/2/2001 10:15 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
> wrote:
>
> > 's OK -- you will thank me the first time you need to update a deployed app on
> > a
> > production server without taking down Catalina :-).
>
> eh?
>

If you install the manager webapp (and set up an appropriate username),
reload-on-command will work for you even on a production server where you don't turn
on "autoreload".

>
> > There is none, and cannot be (for the same reason you cannot write a complete
> > DTD
> > for Ant) -- the set of elements, and the attributes supported by a particular
> > element, are extensible.
> >
> > There is the beginnings of documentation for all of the available options --
> > mostly
> > up to date but not complete yet -- at the following location in the source
> > tree:
> >
> > catalina/docs/config/index.html
>
> Yea, believe it or not, I actually had checked there first, but just didn't
> see it. :-(
>

Amazing ... someone who actually looks at the docs first!!!   :-)

Oh well, getting this stuff up to date is one of my major goals during the beta
cycle -- the code is solid enough that there shouldn't be all that many bugs to fix.

>
> > For anyone who cannot figure out how to get the build to work :-) there is
> > always
> > the nightly binary distributions:
> >
> > http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/
> >
> > Tonight's post (at around 5am Pacific time) will include the fix.
>
> Yea, I was hoping I didn't have to stay up till 5am to get it. :-)
>

You've got mail.

>
> -jon
>

Craig



Re: classreloading and 4.x

Posted by Jon Stevens <jo...@latchkey.com>.
on 1/2/2001 10:15 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:

> 's OK -- you will thank me the first time you need to update a deployed app on
> a
> production server without taking down Catalina :-).

eh?

> There is none, and cannot be (for the same reason you cannot write a complete
> DTD
> for Ant) -- the set of elements, and the attributes supported by a particular
> element, are extensible.
> 
> There is the beginnings of documentation for all of the available options --
> mostly
> up to date but not complete yet -- at the following location in the source
> tree:
> 
> catalina/docs/config/index.html

Yea, believe it or not, I actually had checked there first, but just didn't
see it. :-(

> For anyone who cannot figure out how to get the build to work :-) there is
> always
> the nightly binary distributions:
> 
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/
> 
> Tonight's post (at around 5am Pacific time) will include the fix.

Yea, I was hoping I didn't have to stay up till 5am to get it. :-)

-jon


Re: classreloading and 4.x

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:

> on 1/2/2001 6:22 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
> wrote:
>
> > I just tried this again (against current CVS code) with Vincent's original
> > test
> > cases and it works fine for me.  I can send you the test suite if you like, to
> > verify that it works/doesn't work in your environment.
> >
> > One issue that might cause this appearance is if you don't wait long enough.
> > By
> > default, Tomcat 4.0 checks for classfile changes every 15 seconds, if
> > reloadable
> > is set to true.  You can change this as follows:
> >
> > <Context path="" docBase="scarab" reloadable="true">
> > <Loader checkInterval="5"/>
> > </Context>
> >
> > As an alternative (and this works even on apps that you have not defined as
> > "reloadable" in server.xml), consider this strategy:
> >
> > * Install the "manager" webapp that comes with Tomcat if not
> > present already.
> >
> > * Create a user with role "manager" in server/tomcat-users.xml
> > (actual username and password are arbitrary).
> >
> > * Whenever you want to restart Scarab, issue an HTTP request to:
> > http://localhost:8080/manager/reload?path=/xxx
> > where /xxx is the context path (empty string for the root webapp).
> >
> > * You will need to log on (BASIC authentication) the first time you
> > do this, with the username/password you created above.
>
> Na. That is annoying. :-) I would rather just have this check turned down to
> something like 3 seconds. I didn't realize that there is a Loader
> checkInterval setting.
>

's OK -- you will thank me the first time you need to update a deployed app on a
production server without taking down Catalina :-).

>
> BTW, where is the DTD for the server.xml file? There isn't one defined at
> the top of the file.
>

There is none, and cannot be (for the same reason you cannot write a complete DTD
for Ant) -- the set of elements, and the attributes supported by a particular
element, are extensible.

There is the beginnings of documentation for all of the available options -- mostly
up to date but not complete yet -- at the following location in the source tree:

    catalina/docs/config/index.html


>
> > NOTE:  In reviewing the code, it looks like this won't handle the root webapp
> > correctly until I do a quick bugfix, but the basic principle applies.
>
> Can you email me privately a copy of the fixed server.jar file as I can't
> build Tomcat yet. :-)
>

The patch is in CVS now.  I will send you the test suite I use, and the most recent
"catalina.jar" -- the file of interest is
"org/apache/catalina/servlets/ManagerServlet.class".

For anyone who cannot figure out how to get the build to work :-) there is always
the nightly binary distributions:

    http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/

Tonight's post (at around 5am Pacific time) will include the fix.

>
> thanks,
>
> -jon
>

Craig


>
> --
> Honk if you love peace and quiet.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org


Re: classreloading and 4.x

Posted by Jon Stevens <jo...@latchkey.com>.
on 1/2/2001 6:22 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:

> I just tried this again (against current CVS code) with Vincent's original
> test
> cases and it works fine for me.  I can send you the test suite if you like, to
> verify that it works/doesn't work in your environment.
> 
> One issue that might cause this appearance is if you don't wait long enough.
> By
> default, Tomcat 4.0 checks for classfile changes every 15 seconds, if
> reloadable
> is set to true.  You can change this as follows:
> 
> <Context path="" docBase="scarab" reloadable="true">
> <Loader checkInterval="5"/>
> </Context>
> 
> As an alternative (and this works even on apps that you have not defined as
> "reloadable" in server.xml), consider this strategy:
> 
> * Install the "manager" webapp that comes with Tomcat if not
> present already.
> 
> * Create a user with role "manager" in server/tomcat-users.xml
> (actual username and password are arbitrary).
> 
> * Whenever you want to restart Scarab, issue an HTTP request to:
> http://localhost:8080/manager/reload?path=/xxx
> where /xxx is the context path (empty string for the root webapp).
> 
> * You will need to log on (BASIC authentication) the first time you
> do this, with the username/password you created above.

Na. That is annoying. :-) I would rather just have this check turned down to
something like 3 seconds. I didn't realize that there is a Loader
checkInterval setting.

BTW, where is the DTD for the server.xml file? There isn't one defined at
the top of the file.

> NOTE:  In reviewing the code, it looks like this won't handle the root webapp
> correctly until I do a quick bugfix, but the basic principle applies.

Can you email me privately a copy of the fixed server.jar file as I can't
build Tomcat yet. :-)

thanks,

-jon

-- 
Honk if you love peace and quiet.


Re: classreloading and 4.x

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:

> Ok, I have this in my server.xml:
>
>         <Context path="" docBase="scarab" reloadable="true"/>
>
> Yet when I change a class in my WEB-INF/classes directory, it doesn't get
> reloaded. Any ideas?
>

I just tried this again (against current CVS code) with Vincent's original test
cases and it works fine for me.  I can send you the test suite if you like, to
verify that it works/doesn't work in your environment.

One issue that might cause this appearance is if you don't wait long enough.  By
default, Tomcat 4.0 checks for classfile changes every 15 seconds, if reloadable
is set to true.  You can change this as follows:

    <Context path="" docBase="scarab" reloadable="true">
        <Loader checkInterval="5"/>
    </Context>

As an alternative (and this works even on apps that you have not defined as
"reloadable" in server.xml), consider this strategy:

* Install the "manager" webapp that comes with Tomcat if not
  present already.

* Create a user with role "manager" in server/tomcat-users.xml
  (actual username and password are arbitrary).

* Whenever you want to restart Scarab, issue an HTTP request to:
        http://localhost:8080/manager/reload?path=/xxx
  where /xxx is the context path (empty string for the root webapp).

* You will need to log on (BASIC authentication) the first time you
  do this, with the username/password you created above.

NOTE:  In reviewing the code, it looks like this won't handle the root webapp
correctly until I do a quick bugfix, but the basic principle applies.

>
> -jon

Craig