I've redesigned the Struts configuration scheme to better structure
XWork and Struts internals, allow self-configuring plugins, and reduce
the amount of configuration necessary to write a Struts application -
none, in fact.
The core changes are:
- A new dependency injection engine in XWork (Guice [1])
- XWork and Struts use this DI engine to wire together framework pieces
- Ability to configure settings (previously struts.properties) and
Guice beans in XML
- struts.xml and struts.properties are now completely optional
- Plugins can override any injected Struts bean and provide their own
settings/properties
The primary purpose of these changes was to minimize the amount of
configuration an end user needs to provide in order to create a Struts
application. The secondary goal was to better structure Struts/XWork
internals to make plugins more powerful and, one day, get rid of statics
to allow different configurations of the framework per filter instance,
per package, etc.
My favorite part of the changes is the ability to have a fully
functional Struts app with no additional XML or properties files. Just
set the "actionPackages" property in web.xml, and Struts will scan those
packages and their subpackages for any Actions automatically. The new
plugin features allow you simply drop in a jar like the Plexus plugin
and have its, say, ObjectFactory, automatically used as the default
without you having to provide any extra configuration (plan to move
Spring to its own plugin next).
You might be wondering why Guice, why not Spring, or why a dependency
injection container at all. First, the dependency injection engine is
solely for XWork, Struts, and its plugins. It is not meant, nor would
it be a good fit, for the end user application. Guice has a very
minimal feature set that is perfect for the Struts framework, but
wouldn't be sufficient for a Struts application.
Second, an internal DI container is important as it doesn't force a
Struts application to use a certain DI container for their application.
If we used Spring, the framework would not only require all Struts
applications to have Spring, but also require a certain version. Guice
is not only a very small, fast, DI container, but it also has been
imported into the XWork source repository and package structure, so that
if a Struts application wanted to use a different version of Guice down
the road, it wouldn't be a problem.
Finally, having an internal DI container gives us a standard way of
defining extension points and allowing plugins and users to easily
choose implements of these extension points. Also, a DI container
allows us to get rid of most of our uses of 'static', meaning an
application could use two implementations simultaneously in different
areas. This means getting rid of singletons and unextendable static
classes. An added benefit is the ability to inject things like
constants, the ServletContext, or the current Configuration into any
bean just by declaring an annotation. Finally, testing is easier since
dependencies can be injected via set calls, minimizing setup costs.
The code has been committed, all unit tests are passing, and the
Showcase app seems to be working correctly. Please give it a try so we
can iron out the inevitable bugs as soon as possible. I think this DI
foundation will allow for some very interesting plugins, turning Struts
2 into a deeply customizable, yet turnkey, framework.
http://jira.opensymphony.com/browse/XW-433
http://jira.opensymphony.com/browse/XW-434
http://jira.opensymphony.com/browse/XW-435
https://issues.apache.org/struts/browse/WW-1421
https://issues.apache.org/struts/browse/WW-1402
https://issues.apache.org/struts/browse/WW-1498
Don
[1] http://code.google.com/p/google-guice/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]