You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Brian Pontarelli <br...@pontarelli.com> on 2007/04/30 19:58:23 UTC
Struts plugin and configuration/initialization
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts plugin and configuration/initialization
Posted by Brian Pontarelli <br...@pontarelli.com>.
>>> 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-plugin.xml or struts.xml?
>>
>> For S2, we gave the framework its own XML DTD so that it could be more
>> than just an XWork configuration.
>>
> Both. Ideally any file that is loaded into Struts via the classpath
> would have an opportunity to control the configuration and/or
> initialization/lifecycle of the framework. This could be in a plugin
> JAR, which would probably be the most common. But it could also be
> within an application.
>
> I noticed that it was a different DTD, so it would be possible to use
> it without major modifications as long as the XWork configuration
> system that leverages these files will happily ignore unknown entries.
> Otherwise, the Struts configuration will need to be post processed
> first and then handed to XWork. I'll start taking a look into this an
> see what I can find.
Okay, I've done a lot of work on the new unknown handler, component
framework and configuration mechanism (which would replace zero-config).
This is all working now and I didn't have to make changes to the
configuration mechanism of Struts.
First, I do feel that it is important to still add that handling of
lifecycle, configuration and initialization to Struts. This will allow
plugins much more flexibility and control.
Second, I accomplished this using a custom configuration provider that
must be configured in the web.xml in order for my plugin to work correctly.
Last, I'll send out another email to start a new thread with all of the
information about my plugin. I'm working with the company I developed it
for in order to see if I can open source it and add it as an available
plugin. It shouldn't be too difficult considering a good portion of the
code is already open source because I grabbed it from the zero-config
and codebehind plugins as well as other locations.
I did do some digging into what it would take to add some more support
for lifecycling, configuration and all that jazz and it seems very
doable without being too invasive. However, it will require a separate
block so that beans define outside of XWork won't be picked up by XWork.
Additionally, it seems as though the XWork contain could be used for
dependency injection as well. This would be ideal. The changes would
mostly be to dispatcher and this class would first load everything from
all the XML files. Next it would inject everything using XWork
annotations and container. Next, it would signal to all the lifecycle
listeners that bootstrap was complete and move onto setting up XWork.
After that was done it would signal all the lifecycle listeners again
that XWork was setup and could be post processed. This should be pretty
simple overall and only entail a single interface and some new XML
parsers to handle the new configuration in the Struts XML files.
Thoughts?
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts plugin and configuration/initialization
Posted by Brian Pontarelli <br...@pontarelli.com>.
Ted Husted wrote:
> On 5/1/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>> 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-plugin.xml or struts.xml?
>
> For S2, we gave the framework its own XML DTD so that it could be more
> than just an XWork configuration.
>
Both. Ideally any file that is loaded into Struts via the classpath
would have an opportunity to control the configuration and/or
initialization/lifecycle of the framework. This could be in a plugin
JAR, which would probably be the most common. But it could also be
within an application.
I noticed that it was a different DTD, so it would be possible to use it
without major modifications as long as the XWork configuration system
that leverages these files will happily ignore unknown entries.
Otherwise, the Struts configuration will need to be post processed first
and then handed to XWork. I'll start taking a look into this an see what
I can find.
-bp
Re: Struts plugin and configuration/initialization
Posted by Ted Husted <hu...@apache.org>.
On 5/1/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> 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-plugin.xml or struts.xml?
For S2, we gave the framework its own XML DTD so that it could be more
than just an XWork configuration.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts plugin and configuration/initialization
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <br...@pontarelli.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts plugin and configuration/initialization
Posted by Ted Husted <hu...@apache.org>.
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 <br...@pontarelli.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org