Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 116397 - Why not set reloadable="true" ?
Why not set reloadable="true" ?
Status: RESOLVED FIXED
Product: serverplugins
Classification: Unclassified
Component: Tomcat
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Petr Hejl
issues@serverplugins
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-22 14:32 UTC by _ gsporar
Modified: 2010-04-22 08:34 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ gsporar 2007-09-22 14:32:32 UTC
When I create a web application project with the IDE and set the server to Tomcat, the IDE creates a context.xml file 
for the application.  A typical one would contain:

<?xml version="1.0" encoding="UTF-8"?>
<Context path="/WebApplication4"/>

It seems like there should be an option (perhaps a checkbox that is checked by default?) so that the context.xml 
instead looks like:

<?xml version="1.0" encoding="UTF-8"?>
<Context path="/WebApplication4" reloadable="true"/>

Maybe I am missing something here, but if we are doing directory-based deployment by default, then it seems like we 
should also take advantage of Tomcat's ability to do automatic reloading of classes.  That would allow me to modify a 
servlet, press F9 to just compile that single source file and then go over to my browser and immediately see the result.

FWIW, this is what Eclipse users who are using the popular Sysdeo plugin for Tomcat are used to - it sets 
reloadable="true" by default: http://www.cs.uofs.edu/~bi/eclipse/install-tomcat-plugin.html
Comment 1 Petr Hejl 2007-10-01 20:02:33 UTC
I agree with you this is very useful functionality. We should evaluate the change carefully to be sure that we won't
break anything (debugging for instance). When doing this we should also consider default usage of antiJARLocking - it
could be helpful for clean & build while server is running (see issue 112529).

BTW Reloadable can be set to true by setting it manually in META-INF/context.xml in current nb ide version.
Comment 2 Petr Hejl 2007-10-01 20:08:00 UTC
We should also (if possible) make clear that this option should not be used in production builds.
Comment 3 Petr Hejl 2008-07-22 12:43:53 UTC
Fixed JAR locking (configured antiJARLocking="true" for tomcat 5.5 and 6.0) 07525c2cca71.

Reloadable does not make sense with CoS.
Comment 4 _ gsporar 2008-07-22 14:33:07 UTC
>Reloadable does not make sense with CoS.

What exactly is "CoS" ?

Thanks - Gregg
Comment 5 Petr Hejl 2008-07-22 15:01:05 UTC
Compile/Deploy on Save.
Comment 6 _ gsporar 2008-07-22 15:39:03 UTC
Is there a specification for Compile/Deploy on Save available that explains in a bit more detail why reloadable="true"
is not necessary?

Thanks - Gregg
Comment 7 Petr Hejl 2008-07-22 15:57:25 UTC
http://wiki.netbeans.org/CompileOnSave

It is not necessary because Deploy on Save is doing the exactly the same thing as reloadable.

BTW tomcat is not doing "automatic reloading of classes" as mentioned in first comment. Tomcat just monitors changes in
classes and reload the (whole) application.

With CoS we know when the class is changed and we can call reload directly - doing the same thing.
Comment 8 Quality Engineering 2008-07-23 11:42:29 UTC
Integrated into 'main-golden', available in NB_Trunk_Production #339 build
Changeset: http://hg.netbeans.org/main/rev/07525c2cca71
User: phejl@netbeans.org
Log: #116397 Why not set reloadable="true" ?: Fixed jar locking.
Comment 9 fleka 2010-04-22 08:20:42 UTC
Deploy on Save is great feature, but not always. First of all what if I change 3-4 files (java, properties, etc..) and hit save on each separately? Tomcat will do redeploy after each save which is not very cheap process when working with large webapps.
On the other hand, some of my coworkers (eclipse ones) continuously reminds me that redeploy is not always needed. If I only change log message in some class, only that class needs to be replaced in classpath, which is extremely faster than reloading.

Any suggestions on this?
Comment 10 Milos Kleint 2010-04-22 08:34:45 UTC
my general advice for top-class class reloading is JRebel.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo