There are ways to do this without restarting the server, with JRun 3.0 and
JRun 3.1. Please see below:
Servlets, JSPs and JavaBean classloading in JRun 3.x
- Servlets and regular JavaBeans (not EJBs) are loaded in
JRunServletLoaders. If a Web app has JavaBeans loaded by JSPs and it has
Servlets, the Servlets and the JavaBeans will have been loaded+defined by
the same class loader instance. The defining loader for every
JRunServletLoader is the JVM's system loader:
sun.misc.Launcher$AppClassLoader.
- [JRUN 3.0 ONLY] A trick to force reloading of JavaBean classes used by a
JSP, is to change or touch a Servlet class file in the same Web app. This
will cause the entire Web app to be dumped, along with the old JavaBean(s)
of course. Now request the JSP (you don't have to even touch or change it,
because the whole Web app is gone at this point) and it will be reloaded
with the new instance of the bean. Easier than restarting server? A
little, but not much. In JRun 3.1 this won't work the same way; if you
change a Servlet the old JRunServletLoader sticks around if there are any
JSPs referencing JavaBeans in it. Only new Servlet requests are redirected
to the new JRunServletLoader. To dump the whole app, trigger an
auto-redeploy (see next section).
Hot Deploy/Auto-Redeploy in JRun 3.1
- In JRun 3.1, hot redeploy makes it easy to "restart" an entire Web
application. The easiest way to do it is just to touch a web.xml or
webapp.properties, or touch a zip or jar file in the lib directory. All
servlets and JSPs will be destroyed, along with their classloaders, and
changes to web.xml and/or webapp.properties will be read in. Naturally, hot
deploy has to be enabled (search global.properties for documentation and
relevant properties).
- The main differences between auto-redeploy and servlet reloading in JRun
3.1 are these:
- auto-redeploy reloads ("restarts" is more accurate) an entire app, not
just individual components. So, for example, pre-loaded servlets in your
Web app will be destroyed and pre-loaded again.
- Hot deploy and auto-redeploy are based solely on monitoring of file
system timestamp changes.
- By default, hot deploy/auto-redeploy monitors web.xml, webapp.properties,
zips and jars in WEB-INF/lib, and *.war files in the deploy directory.
- Changes to any loose Servlets in WEB-INF/classes and WEB-INF/lib are
handled by the regular old dynamic reload mechanism in
allaire.jrun.servlet.JRunSE. These reloads are initiated by HTTP requests,
and depend on timestamp changes between class files on disk and in-memory
copies. Remember, classes in jars and zips are only reloaded by
auto-redeploy.
Scott Stirling
JRun QA
Macromedia
> -----Original Message-----
> From: Haseltine, Celeste [mailto:[EMAIL PROTECTED]]
>
>
> Nick,
>
> That is correct. While the jsp's are recompiled if they have
> changed since
> they were last "touched", Java class objects are loaded into
> memory the
> first time they are called, and remain resident in memory
> until you shut
> down the server. Therefore, during the development phase,
> you will need to
> shut down and restart your JRUN server every time you
> recompile your Java
> class objects.
>
> Celeste
>
> -----Original Message-----
> From: Nick de Voil [mailto:[EMAIL PROTECTED]]
>
>
> JRun only seems to pick up a new .class of a custom tag
> handler if I restart
> the server.Is that right or am I missing something?
>
> Thanks
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get the mailserver that powers this list at http://www.coolfusion.com
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
