Hi, Sven.

Down below...

----- Original Message -----
From: "Sven K�hler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 14, 2003 02:04
Subject: Re: AW: modified jsp-files and jasper2


> > It can take up to 15 seconds (default) for Tomcat to poll for changes to
> > class files.  The frequency of how often Tomcat checks can be changed
via
> > the Loader checkInterval property in the containing Context node.
Ensure
> > Context.reloadable and Loader.reloadable are not set to false; they are
true
> > by default.
>
> according to the docs, this config should do:
>
>      <servlet>
>          <servlet-name>jsp</servlet-name>
>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
>          <init-param>
>              <param-name>logVerbosityLevel</param-name>
>              <param-value>WARNING</param-value>
>          </init-param>
>          <init-param>
>              <param-name>compiler</param-name>
>              <param-value>jikes</param-value>
>          </init-param>
>          <init-param>
>              <param-name>development</param-name>
>              <param-value>false</param-value>
>          </init-param>
>          <init-param>
>              <param-name>reloading</param-name>
>              <param-value>true</param-value>
>          </init-param>
>          <init-param>
>              <param-name>checkInterval</param-name>
>              <param-value>10</param-value>
>          </init-param>
>          <load-on-startup>3</load-on-startup>
>      </servlet>
>
> BUT:
> 5 minutes ago, i had a case, where it didn't work.
> The page was uploaded an hour ago, but you still couldn't see the
> correct page online. I checked the work-folder, and the jsp-page has
> _not_ been compiled. the old .java and .class file was still there.

I just checked the web.xml file in $CATALINA_HOME/conf/web.xml.  It suggests
the "development" is the default mode in which Jasper operates.  Have you
tried leaving development, reloading, and checkInterval out of your web.xml
file to see if the standard behavior works?

> Hitting the reload-button in the manager-app always helps.

It shouldn't help; it either works or it doesn't.  You should also note that
there can be several seconds lag associated with having Tomcat actually
carry out a reload.

[ Aside:  Does manager/reload fail if Context.reloadable=false? ]

> we also uploaded another update of the same page, and this time, the
> jsp-page was recompiled, and we could see the new page - as it should
> normally be.
>
> The "reloadable" property of the context shouldn't matter, because it's
> for the files in the WEB-INF-folder (it says, whether they can will be
> automatically reloaded or not)
>
> hitting the reload-button in the manager-app shouldn't help at all,
> because the classes generated from JSP-files should be reloaded by Jasper.
>
> Even if i'm wrong, it should always _not_ work, or always work, but not
> like it is now: it works sometimes, but not always

You have not mentioned your reloadable settings in server.xml.  I am
inclined to believe that reloading class files for a web application is
handled in one place--no matter where those file reside.

> > I am uncertain whether or not JSP files are included in this particular
> > check or if there is another layer elsewhere.  But a good guideline is
to
> > wait for at least 60 seconds before testing newly uploaded JSP files.
>
> You also tell me, that the checkInterval-Option of Jasper is completly
> useless? and i would have to wait 60sec?
>
> We waited more than 60sec, but it didn't work.

I suggested 60 seconds for this...

1) There has been a change.
2) Jasper translates the file.
3) Jasper compiles the file.
4) Tomcat takes up to 15 seconds at this point to determine that it needs to
reload a class file.

I wasn't implying that the checkInterval number was useless--just that there
is more processing to reloading a class than mere class file datetime compar
isons.

By your tone, it sounds like you only conducted this experiment once.

If I were you, I would start with the most simple system for base testing
and then add complexity in increments.  Consider goes with these phases:

1) Simple local system...

a) Use a local development machine for this test.
b) Use a serverl.xml file with no reloadable configuration
<Context.reloadable> and <Loader.reloadable> set to true.
c) Use a web.xml file without org.apache.jasper.servlet.JspServlet
configuration information--use the default configuration.
d) Start Tomcat.
e) Access a jsp file using http://localhost:8080/...
f) Copy a file overtop the existing JSP (or modify the exiting JSP and save
it).
g) Access the jsp file again. (the default "development" configuration
should cause Jasper to translate and compile the JSP file)
h) Wait 15 seconds or so. (for the class reloader to finish its sweep)
i) Access the jsp file again.  (hopefully you will have witnessed a change
here)

Steps h and i may or may not be necessary because I don't know whether or
not Jasper prompts class reloading or lets that happen during standard
processing.

2) Simple remote system...

Same as (1) except that you should try editing the JSP file in place.  Or if
you upload a JSP file, make sure that you "touch" it.  Hopefully you will
see results.

3) More complicated remote system...

Same as (2) except that you should try uploading the JSP file.  Check from a
shell on the file datetime value.

4) Even more complicated remote system...

Here you can start messing with the configuration files a little bit (and
then a little bit more).

Reloading of applications does work for lots of people.  I am sure that if
you start from the baseline, you will discover something that was not
previously understood about how the reloading process works or perhaps work
a kink out of your configuration.

Good luck.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to