struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: initConfigDigester refactoring?
Date Wed, 17 Jul 2002 15:26:10 GMT

On Wed, 17 Jul 2002, Jesse Alexander (KADA 11) wrote:

> Date: Wed, 17 Jul 2002 09:22:09 +0200
> From: "Jesse Alexander (KADA 11)" <>
> Reply-To: Struts Developers List <>
> To: Struts Developers List <>
> Subject: RE: initConfigDigester refactoring?
> Hi,
> 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).

Is that like the <set-property> element that is used various places in
struts-config.xml files, for exactly this purpose?

> 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
> parties.
> Maybe something similar could ease the Gotcha in Brian's idea.

The "arbitrary property" works great when you only want to add a couple of
JavaBeans properties to some subclass you are configuring.  It doesn't
work so well for more complex cases, as Brian illustrated in his response.

It also completely breaks down when you'd prefer to have an entire set of
nested XML elements and attributes for use in configuring the component,
instead of just a set of additional attributes on one element.

> regards
> Alexander


> -----Original Message-----
> From: Brian Topping []
> Sent: Dienstag, 16. Juli 2002 13:24
> To:
> 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.
> -b
> 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.
> -b
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message