Home > Guides > Core Developers Guide > Zero Configuration |
Deprecated Plugin
Since 2.1 this plugin has been deprecated in favor of the Convention Plugin
A "Zero Configuration" Struts application or plugin uses no additional XML or properties files. Metadata is expressed through convention and annotation.
As this is a new feature, and still being field-tested, the documentation is sketchy. But, here's what we have so far:
Set the "actionPackages" filter init param to a comma-separated list of packages containing Action classes in web.xml. The packages and their subpackages will be scanned. All classes in the designated packages that implement Action or end in "Action" are examined. The latter is to allow for POJO Actions that don't implement the Action interface.
<filter> <filter-name>struts2</filter-name> <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class> <init-param> <param-name>actionPackages</param-name> <param-value>com.foo.bar,com.baz.quux</param-value> </init-param> </filter>
We should probably add an action annotation, so that POJOs can itall with annotations.
The only example right now is in the showcase, where the person package uses the classpath scanning configuration.
The subpackage name makes the namespace, and the action class name makes the action name. If there is an "Action" suffix, it is dropped before creating the action name. Therefore, if the configured package is com.myapp.actions and the Action is com.myapp.actions.member.EditAction, you can access it via http://server/myapp/member/edit.action. For multi-word actions, the first letter is lower-cased and the rest is left alone, so the Action MyCustomAction
will map to myCustom.action
.
Results are defined with the Result and Results annotations at the class level.
The Namespace Annotation overrides the namespace.
The ParentPackage Annotation configures the XWork package (an XWork package is created per Java package) to extend one or more defined packages. The best place for this annotation is on the package via the package-info.java
file, however, for backward-compatibility, they can be specified on one or more Actions in the package. To determine which parent packages should be set, first, it looks for the package annotation, then adds the action annotations as they are loaded. Because the load order of Actions is undetermined, it is highly recommended you avoid putting the @ParentPackage annotation on Action classes themselves.
For example, if you wanted to set the parent package for the com.mycompany.myapp.actions
package, create this package-info.java file:
@ParentPackage("my-parent-package") package com.mycompany.myapp.actions import org.apache.struts2.config.ParentPackage;
To define multiple parent packages, list an array of package names:
@ParentPackage({"my-parent-package1, my-parent-package2"}) package com.mycompany.myapp.actions import org.apache.struts2.config.ParentPackage;
Stay tuned to this page for additional details and documentation. If you have a chance to try the zero configuration feature, please share any experiences on dev@ and here.