Commented on that issue, but it appears to be the same at the root of
the issue. If we can control the lifecycle better and have plugin points
at each lifecycle stage as well as plugin points for new
ConfigurationProviders we should be able to handle most of these types
of cases.
I think perhaps it warrants a bit of discussion because if I were going
to tackle it I might be inclined to suggest that the struts-plugin.xml
be converted from an XWork configuration file to a new XML format that
would have a section specifically for XWork configuration and a separate
section for Struts configuration. Something like:
<struts>
<configuration_provider>com.example.ConfigProvider</configuration_provider>
<lifecycle_listener>com.example.Lifecycle</lifecycle_listener>
...
<xwork>
<pacakge name="foo">
...
</package>
...
</xwork>
</struts>
The top configuration would be handled by an outer container that would
bootstrap everything and then manage the lifecycle of the Struts
framework. The xwork would then be used when configuring xwork. Ideally,
the top beans would be able to be dependency injected in the same manner
as the xwork beans, but would only be able to see Struts objects and
J2EE objects.
Thoughts?
-bp
Ted Husted wrote:
It would be nice if the refactoring would make it easier to implement
"Automatic Alias ActionConfigs"
* https://issues.apache.org/struts/browse/WW-1522
As I remember, we ran aground of the same kind of problem.
On 4/30/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Right now the struts plugin architecture is setup to allow plugins to be
processed once XWork has been setup, configured and initialized. This
makes it difficult to change the configuration and initialization
process for Struts and Xwork without sub-classing the FilterDispatcher
and overriding methods in a Dispatcher sub-class. Although this isn't
difficult, it doesn't make using a plugin as simple as dropping it into
the WEB-INF/lib directory, nor does it allow multiple plugins to change
the configuration/initialization process.
I'd like to propose fixing this by moving the plugin handling a level
higher and allowing plugins to add beans that could participate in the
configuration and initialization of everything.
I haven't got a firm interface or class structure in mind, but I wanted
to start some discussion first before I went down to that level of
detail.
Perhaps another plugin feature would be to move the dependency injection
that is leveraged by XWork (effectively Guice pre 1.0) higher so that it
could be leveraged by this new plugin structure as well.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
