VelocityTools 2.0 marks the most significant set of upgrades and changes ever done for the VelocityTools library. In order to provide flexible configurations, lazy-loading for tools, and a host of other improvements, almost all of the tool management and configuration code from Tools 1.x has been deprecated and replaced by completely different APIs. Thankfully, we were able to continue supporting old toolbox.xml configuration files and old tool design patterns, though these too have been deprecated and are unable to take full advantage of many of the new features.
Still, as such things have only been deprecated and not removed, the first step in upgrading to 2.0 is simply replacing your old VelocityTools jar with the 2.0 jar. If this causes any errors for you, please report them to email@example.com, so that we can fix it and help you work around it in the meantime.
Once you have your application compiling and running with Tools 2, your next step is to begin updating or replacing deprecations. Many of these should show up with deprecation warnings during compiling or deprecation notices in your logs. Read through these carefully to be aware of all that needs updating. Below is a list of instructions for handling many of these:
In general, anything in the packages:
has been moved to:
The extra packages had proved superfluous and problematic. All VelocityView classes are now in the
org.apache.velocity.viewpackage. Those that remain in the subpackages are merely deprecated shells that extend the classes in the new location. Also, some classes have had their class names adjusted to be more consistent with existing conventions.
Some specific ones to watch out for are as follows. If you directly referenced:
NOTE: If you are still using the old toolbox.xml format do NOT update the tool paths in that file! First, update your configuration, otherwise your tools may not work as expected. Also, this is not a complete list. Please take note of all deprecation warnings and notices when compiling and running your app.
Along with the class renamings above have come many deprecations that have no one-to-one replacement class. The vast majority of these have to do with tool management, as XMLToolboxManager and all of its subclasses and support classes could not simply be evolved to achieve the key goals for Tools 2. A few other classes are simply no longer necessary in any form. Here is an overview of all these deprecations-without-direct-replacements:
XMLToolboxManager was the the central tool management class in Tools 1.x. If you used it or ServletToolboxManager you were probably a more advanced user or a framework developer working to integrate VelocityTools support. If so, you should go read this document . If you used XMLToolboxManager directly, you should familiarize yourself with these classes:ToolManager or VelocityView should be all they really need to work with directly. Don't waste time trying to manage
Toolboxes yourself until you are sure that ToolManager/VelocityView can't do the job for you.
All of the upgrades to tool management allowed some GenericTool classes to perform functions previously only possible to implement in VelocityView tools. As such, some VelocityView subclasses of generic tools have become obsolete. If you used:
Since Tools 2 does lazy-loading of tools, it now makes sense
to have almost all tools available by default for most uses,
as there is minimal overhead for that at startup and essentially
no cost at runtime unless/until the tool is used. So,
in Tools 2, unless the
user is doing something to trigger the "deprecation support mode" for
VelocityView (using the old toolbox.xml format would do this)
or explicitly telling
not to load the default tools, then all of the supported,
standard VelocityTools will be automatically made available by
default. If you don't custom configure any of the provided tools
and don't have any custom tools of your own, then you don't actually
need a configuration at all! Tools 2 comes with a default tools.xml
file each for GenericTools, VelocityView and VelocityStruts, and
will all automatically look for
and load those unless you are using a deprecated toolbox.xml file
or explicitly tell them not to by adding the init-param
with the value of false
to the relevant servlet.
If you do need a configuration, you should update your configuration to one of the new formats. Easiest would be to go from the old xml format to the new xml format. Remember, you can just leave out standard tools that you don't do any configuration of, as your configuration will just be added to the default one (again, unless the default behavior is turned off). Also, do note that all VelocityView tools have changed packages and/or names; please avoid using the deprecated versions as those will eventually be removed.
If you are largely happy with the default tools.xml configuration, but wish to override just a few parts, you can override them with your own file. Tool configurations are key-centric. If you just want to provide a different default format for the DateTool and a second bundle for the ResourceTool, your tools.xml can be just:
<tools> <toolbox scope="application"> <tool key="date" format="MM/dd/yy"/> </toolbox> <toolbox scope="request"> <tool key="text" bundles="resources,otherResources"/> </toolbox> </tools>
This just overrides the format property of the "date" tool and the bundles property of the "text" tool in the configuration. Since "date" and "text" already have classes set in the default tools.xml files that come with the GenericTools and VelocityView packages, you don't need to include those.
Those of you who write your own custom tools may want to make a few changes to upgrade your custom tools to do things the "Tools 2 way". Here's a few quick starts for that, though this doesn't cover everything. More details can be found in the instructions for creating tools.
The recommended practice is to give a tool to be used as
This is not required but is a convention that keeps things easy
follow and learn. If you have to name a tool FooBarUtility but want
it to be
in templates, the second best thing is to
annotation on the class, though this introduces a dependency on
VelocityTools. As a last resort, if you are providing tools
for a framework or otherwise can influence or control the configuration,
you might consider providing a default configuration--perhaps even
one automatically discoverable by
set the tool's key for your users.
If your tool is only meant to be used in a particular scope,
it's recommended that you give the class a
annotation as well. If you only want to ban a particular scope and
allow all others, you could provide a
annotation on the class. The
class provides constants for
REQUEST, SESSION, and APPLICATION. Other scopes are now
theoretically possible, but only a little work and no testing has
been done there at this point.
Configuration: If you have a configurable tool whose configuration should not changed by the templates which use it, then consider having your tool extend the SafeConfig class (or FormatConfig or LocaleConfig ). These safely standardize configuration of these common configuration properties. Also take note that the configure(Map) and init(Object) methods have been changed into just the configure(Map) and individual setter methods (e.g. setRequest, setSession, etc). Basically, when it's time to instantiate a tool, the tool manager will gather all the "configuration properties" for that tool, its toolbox, etc and combine it into a single map with the "init data" (context, request, session, etc). The manager searches for relevant setter methods that accept that data and also for a configure(Map) method. The setters get what they're asking for (if available) and the configure() method accepts the whole combined Map. The upshot of this approach is that tools no longer need to conform to any interfaces or patterns. In fact, it's possible to write a FooTool that doesn't know anything about any VelocityTools classes whatsoever and yet be fully instantiable and configurable by VelocityTools. Your tools don't need to know about anything except what they need to know about.