struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Alexander (KADA 11)" <>
Subject RE: initConfigDigester refactoring?
Date Wed, 17 Jul 2002 07:22:09 GMT

about the config-file, validation and extension...
We have in our framework a configuration file (XML...) that
is validated against a dtd. But it remains extensible.
We do it by allowing at various places inthe dtd a
property-attribute (which basically is a mapping for a name-value pair).
In this way the values that must be validated go into the dtd and
can be also defaulted. Who needs special-values can put them
into property-attributes that can then be read by the interested 

Maybe something similar could ease the Gotcha in Brian's idea.


-----Original Message-----
From: Brian Topping []
Sent: Dienstag, 16. Juli 2002 13:24
Cc:; Jeff Pennal
Subject: RE: initConfigDigester refactoring?

> 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: <>

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

View raw message