tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: classreloading and 4.x
Date Wed, 03 Jan 2001 23:37:11 GMT
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!




Mime
View raw message