I have a couple of questions/thoughts/observations that have arisen:
- the chain configuration appears to apply across the application as
a whole rather than per module. This differs from the 1.2 request
processor which can be varied/subclassed on a per module basis. (Of
course, you can still subclass RequestProcessor on a per-module
basis, but the whole point of the chain is that you should not need
to do that)
well, I think we have found that very few active Struts developers
use modules, so some module-centric things get overlooked,
unfortunately.
That said, the per-application config is the loading of the catalog
factory. It *is* possible to change which command is looked up in
the catalogs and executed to process the request as part of the
controller-config on per-module basis.
- the chain seems to be quite good at allowing you to vary the
request processing flow. It is more difficult to apply configuration
or make services accessible to groups of commands in the chain. One
way I can see to do this is by subclassing
ComposableRequestProcessor (not that old chestnut again), overriding
init(ActionServlet,ModuleConfig), then adding the relevant services
to the chain context, using getApplicationScope().put(...). Another
way, apparently, would be to load the configuration in the
constructor or synchronized block of one of the chain commands, then
use
getApplicationScope().put(). It would be nice if you could configure
chain commands using some form of dependency injection, a la Spring,
and allow these services to be added via the chain config file. (I
suppose I should be addressing this to the chain developers mailing
list, although I suspect that most of the chain developers are on
this list as well).
(yes, I think this is effectively the chain developers list :) )
Don't forget that you can configure basic properties on any command
simply by setting xml attributes and letting digester and beanutils
handle the population. This is limited to values, not references,
and is limited by all the limitations for type conversion that
BeanUtils has, but it can still get you pretty far.
It's not so elegant, but for anything beyond that, I'd probably just
have command properties whose values were spring bean names, and then
have the command retrieve the Spring ApplicationContext from the
ServletContext, and look up a bean from there.
Of course, it's possible to create commands and chains in a spring
beans XML file too; it's a bit awkward in terms of syntax, but it can
be done. Technically, you could create an entire alternative
CatalogFactory in Spring (or as many as you like) -- there's just no
good way to inject a CatalogFactory instance into a
ComposableRequestProcessor instance, because of the way that Struts
initialization happens. You could have a
SpringAwareComposableRequestProcessor which found the Spring
ApplicationContext during the init(...) method and looked up its
CatalogFactory there.
I think that in general, the Struts 1.x initialization process is
awfully constraining, but I haven't had any substantially better
ideas about how to do it.
Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
