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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
