struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Topping" <>
Subject RE: initConfigDigester refactoring?
Date Tue, 16 Jul 2002 11:24:16 GMT
> From: Craig R. McClanahan []
> This is an interesting idea.  I see a pretty serious 
> potential gotcha --
> Struts performs a validating parse of the struts-config.xml 
> file, and this
> is required (as of recent nightly builds) because we rely on 
> some default
> values set in the DTD.  Thus, even if you could extend the ruleset to
> recognize more things in struts-config.xml, the validating parser will
> choke on them unless the DTD is modified.

Hi Craig,

Wow, is this for 1.1?  I thought you guys were in beta -- bug fixes on
showstoppers, final candidate builds, yah? :)  

Seriously though, I've been thinking for a while on the implications of
*requiring* config file validation, and while I can imagine there is some
problem that was gracefully solved by it, these restrictions seem to neuter
parallel RequestProcessor implementations, at least as far as I understand
the servlet initialization path, which I believe I have seen most of now.  

Put another way, if the only RequestProcessor that can have first-class
configuration information is the default one built into Struts, what point is
there in having the RequestProcessor split out at all?  It seems like you
still have to subclass ActionServlet, you still have to configure the
separate subclass into web.xml, yada yada, and most of the effort that was
put into consolidating applications in 1.1 is suddenly for naught.

Don't get me wrong, I'm a big fan of validation of config files.  And I know
it's hard to keep a DTD up-to-date in an OSS project if validation is not
required.  So I don't want to sound like a stick in the mud about it.  But I
think a pattern needs to be chosen between 1:1 or 1:n regarding
servlet:application.  Without a significant deprecation of one or the other,
the competing paradigms will end up consuming valuable project energy.

Last time I looked, there was a non-trivial amount of work going into Cocoon
for Sitemap DTDs, but since the DTD is a function of the current Avalon
configuration, it's a pretty fluid target.  I doubt things are much different
with Digester.  

Okay, enough hot air.  Thanks for your consideration on this.


p.s. - the application that I am porting is Struts-XSL.  It basically allows
for the configuration of Cocoon-ish pipelines within a Struts action, without
the overhead of Cocoon.  Everything is operational except the Digester/config
stuff.  But the StXX pipeline configuration is arbitrary repetition of
<transform/> elements, so putting them in set-value elements is too unwieldy.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message