maven_tapestry collection_tapestry5

tapestry5tapestry5

One of the best features of Tapestry is automatic reloading of changed classes and templates. Page and component classes will automatically reload when changed. Likewise, changes to component templates and other related resources will also be picked up immediately. In addition, starting in version 5.2, your service classes will also be reloaded automatically after changes (if you're using Tapestry IoC).

Only certain classes are subject to reload. Reloading is based on package name; the packages that are reloaded are derived from the application configuration.

If your root package is org.example.myapp, then only classes in the following packages (and their sub-packages) will be scanned for automatic reloads:

org.example.myapp.pages

org.example.myapp.components

org.example.myapp.mixins

org.example.myapp.base

org.example.myapp.services (Tapestry 5.2 and later, with restrictions)

Starting in Tapestry 5.2, live class reloading includes service implementation classes. There are some limitations to this. See Service Implementation Reloading for more details.

On occasion, you may need to know when invalidations occur, to clear your own cache. For example, if you have a binding that creates new classes, the way PropertyConduitSource does, you need to discard any cached classes or instances when a change is detected in component classes.

You do this by registering a listener with the correct InvalidationEventHub service.

For example, your service may be in the business of creating new classes based on component classes, and keep a cache of those classes:

Here, the service implementation implements the InvalidationEventListener intece, as well as its service intece. The question is: how does it register for notifications?

In your module, you will want to use a service builder method, such as:

This is the intent of service builder methods; to do more than just injecting dependencies.

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:

and that this isn't being overridden to "true" on your application's startup command line.

If LCR works for you but is slow (more than a second or two), consider the following.

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.

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 -XX:MaxPermSize=400m

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-32012-1.html