> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
