tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r991288 - in /websites/production/tapestry/content: cache/main.pageCache class-reloading.html
Date Fri, 24 Jun 2016 02:19:40 GMT
Author: buildbot
Date: Fri Jun 24 02:19:40 2016
New Revision: 991288

Log:
Production update by buildbot for tapestry

Modified:
    websites/production/tapestry/content/cache/main.pageCache
    websites/production/tapestry/content/class-reloading.html

Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/tapestry/content/class-reloading.html
==============================================================================
--- websites/production/tapestry/content/class-reloading.html (original)
+++ websites/production/tapestry/content/class-reloading.html Fri Jun 24 02:19:40 2016
@@ -126,7 +126,7 @@
 </div></div><p>This is the intent of service builder methods; to do more
than just injecting dependencies.</p><h2 id="ClassReloading-CheckingForUpdates">Checking
For Updates</h2><p>The built in InvalidationEventHub services provide notifications
of changes to component classes, to component templates, and to component message catalogs.
If you wish to check some other resources (for example, files in a directory of the file system
or rows in a database table), you should register as an <a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/UpdateListener.html">UpdateListener</a>
with the <a  class="external-link" href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/UpdateListenerHub.html">UpdateListenerHub</a>
service.</p><p>Periodically (the frequency is configurable), UpdateListeners are
notified that they should check for updates. Typically, UpdateListeners are also InvalidationEventHubs
(or provide Invali
 dationEventHubs), so that other interested parties can be alerted when underlying data changes.</p><h2
id="ClassReloading-TroubleshootingLiveClassReloading">Troubleshooting Live Class Reloading</h2><h3
id="ClassReloading-QuickChecklist">Quick Checklist</h3><ul><li>"Production
Mode" must be false (in Tapestry 5.3 and later)</li><li>The class must be one
that Tapestry instantiates (a page, component, or mixin class, or a Tapestry IOC service implementation
that implements an interface)</li><li>Turn on "Build Automatically" in your IDE,
or remember to build manually.</li><li>Turn <em>off</em> JVM hot code
swapping, if your servlet container supports it.</li><li>Eclipse: Uncheck the
"derived" checkbox for the Target dir (in the Project Explorer view, right click on "target",
select properties, uncheck "derived" on the Resource tab)</li></ul><p>Some
of these issues are described in more detail below.</p><h3 id="ClassReloading-IfLiveClassReloadingdoesn'twork">If
Live Class Reloading doesn
 't work</h3><h4 id="ClassReloading-ProductionMode">Production Mode</h4><p>Starting
with Tapestry 5.3, Live Class Reloading only works when not in "Production Mode". Check your
application module (usually AppModule.java) to be sure you have:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">configuration.add(SymbolConstants.PRODUCTION_MODE,
"false");
 </pre>
-</div></div><p>and that this isn't being overridden to "true" on your application's
startup command line.</p><h4 id="ClassReloading-BuildPathIssues">Build Path Issues</h4><p>Live
Class Reloading can fail if your build path isn't set correctly, and the exact configuration
may differ between Maven plugin versions and Eclipse versions. The build process must be set
to create classes in a folder which is in the servlet container's classpath.</p><p>Live
Class Reloading won't work correctly with vanilla Tomcat without some tweaks (see below).</p><p>Non-Tapestry
filters can interfere with LCR. Try disabling other filters in your web.xml file to see if
that helps.</p><h4 id="ClassReloading-BuildingAutomatically">Building Automatically</h4><p>Although
LCR allows you to see changes without restarting your app, you still need to "build" your
project (to compile the Java source into byte code). Your IDE can be set to do this automatically
every time you save a file. (In Eclipse, this is done us
 ing <code>Project &gt; Build Automatically</code>.) Alternatively, you can
manually trigger a build after you save a file. (In Eclipse, this is done using <code>Project
&gt; Build</code>, or by pressing <code>Control-B</code>.)</p><h4
id="ClassReloading-TurnoffJVMhotcodeswapping&amp;automaticrestarts">Turn off JVM hot
code swapping &amp; automatic restarts</h4><p>Many servlet containers, including
Tomcat and Jetty, support various forms of hot code swapping and/or automatic restarts when
file changes are detected. These are generally <strong>much slower</strong> than
LCR and usually should be turned off with Tapestry applications. If you're using RunJettyRun
plugin for Eclipse, for example, edit your Run Configuration, and on the Jetty tab, click
Show Advanced Options and uncheck the Enable Scanner checkbox.</p><h3 id="ClassReloading-TomcatSpecifics">Tomcat
Specifics</h3><p>See <a  class="external-link" href="http://docs.codehaus.org/display/TYNAMO/Developing+with+Tomcat+and+Eclipse
 " rel="nofollow">these hints</a></p><h3 id="ClassReloading-IfLiveClassReloadingworksbutisslow">If
Live Class Reloading works but is slow</h3><p>If LCR works for you but is slow
(more than a second or two), consider the following.</p><ul><li>Be sure
your project source files (your workspace in Eclipse, for example), are on a local drive,
NOT a network location. Network drives are always slower, and the file system scanning needed
for LCR can add a noticable lag if I/O is slow. If you use Maven, be sure to put your local
repository (e.g. ~/.m2/repository) on a local drive for similar reasons.</li><li>Since
LCR adds classes to your PermGen space, you may be running low on PermGen memory (and may
eventually get a "java.lang.OutOfMemoryError: PermGen space" error). Try increasing PermGen
size with a JVM argument of something like <code>-XX:MaxPermSize=400m</code></li></ul><p></p></div>
+</div></div><p>and that this isn't being overridden to "true" on your application's
startup command line.</p><h4 id="ClassReloading-BuildPathIssues">Build Path Issues</h4><p>Live
Class Reloading can fail if your build path isn't set correctly, and the exact configuration
may differ between Maven plugin versions and Eclipse versions. The build process must be set
to create classes in a folder which is in the servlet container's classpath.</p><p>Live
Class Reloading won't work correctly with vanilla Tomcat without some tweaks (see below).</p><p>Non-Tapestry
filters can interfere with LCR. Try disabling other filters in your web.xml file to see if
that helps.</p><h4 id="ClassReloading-BuildingAutomatically">Building Automatically</h4><p>Although
LCR allows you to see changes without restarting your app, you still need to "build" your
project (to compile the Java source into byte code). Your IDE can be set to do this automatically
every time you save a file. (In Eclipse, this is done us
 ing <code>Project &gt; Build Automatically</code>.) Alternatively, you can
manually trigger a build after you save a file. (In Eclipse, this is done using <code>Project
&gt; Build</code>, or by pressing <code>Control-B</code>.)</p><h4
id="ClassReloading-TurnoffJVMhotcodeswapping&amp;automaticrestarts">Turn off JVM hot
code swapping &amp; automatic restarts</h4><p>Many servlet containers, including
Tomcat and Jetty, support various forms of hot code swapping and/or automatic restarts when
file changes are detected. These are generally <strong>much slower</strong> than
LCR and usually should be turned off with Tapestry applications. If you're using RunJettyRun
plugin for Eclipse, for example, edit your Run Configuration, and on the Jetty tab, click
Show Advanced Options and uncheck the Enable Scanner checkbox.</p><h3 id="ClassReloading-TomcatSpecifics">Tomcat
Specifics</h3><p>See <a  class="external-link" href="http://docs.codehaus.org/display/TYNAMO/Developing+with+Tomcat+and+Eclipse
 " rel="nofollow">these Tomcat-specific hints</a></p><h3 id="ClassReloading-IfLiveClassReloadingworksbutisslow">If
Live Class Reloading works but is slow</h3><p>If LCR works for you but is slow
(more than a second or two), consider the following.</p><ul><li>Be sure
your project source files (your workspace in Eclipse, for example), are on a local drive,
NOT a network location. Network drives are always slower, and the file system scanning needed
for LCR can add a noticable lag if I/O is slow. If you use Maven, be sure to put your local
repository (e.g. ~/.m2/repository) on a local drive for similar reasons.</li><li>Since
LCR adds classes to your PermGen space, you may be running low on PermGen memory (and may
eventually get a "java.lang.OutOfMemoryError: PermGen space" error). Try increasing PermGen
size with a JVM argument of something like <code>-XX:MaxPermSize=400m</code></li></ul><p></p></div>
       </div>
 
       <div class="clearer"></div>



Mime
View raw message