Hi guys, There might be a fix releated to this (https://issues.apache.org/struts/browse/WW-1489) that seems to be broken. WW-1489 abstracted the common logic from both DispatcherFilter and ActionContextCleanUp to an Abstract filter. With the latest commit, FilterDispatcher is put back to its old state (plus the new DI code) and AbstractFilter was deleted.
I guess its ok to revert back to the old state but ActionContextCleanUp is not reverted totally to its old state, such that it doesn't initialize Dispatcher etc. The consequence i guess would be that sitemesh will not have access to struts2 value stack etc. Is this the itended behaviour or am i missing something? Tia Don Brown <[EMAIL PROTECTED]> wrote: 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] Send instant messages to your online friends http://uk.messenger.yahoo.com
