On Tue, 16 Jul 2002, Brian Topping wrote:
> Date: Tue, 16 Jul 2002 07:24:16 -0400
> From: Brian Topping <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], Jeff Pennal <[EMAIL PROTECTED]>
> Subject: RE: initConfigDigester refactoring?
>
> > 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? :)
>
We are in beta, but the gotcha would be present even if we were not in
feature freeze right now -- the XML parser will choke on the extra
parameters that you want your custom RuleSet to process.
> 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,
(Long story, but ...) in our particular case, it solves the problem of
making some servlet context attributes Serilaizable so that Struts apps
will run at all on some popular containers.
The other important benefit is for tools that can build high quality
editing interfaces for the configuration information. Try to build an
admin tool that understands all possible configurations of Tomcat 4's
server.xml file for a fairly extreme example of this.
> 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.
>
I will grant you that there's no way to customize them with standard
JavaBeans properties on the request processor itself. It is not correct
to say that it's impossible to configure request processor instances in
struts-config.xml files. Here's a couple of ways off the top of my head:
* Custom plug-in that configures things (the idea I quoted yesterday).
* Custom implementation of org.apache.struts.config.ControllerConfig
(corresponds to the <controller> element) with extra properties that
you can set with <set-property> elements nested inside.
<controller className="mypackage.MyControllerConfig" ...>
<set-property name="foo" value="bar"/>
<set-property name="baz" value="123"/>
</controller>
These properties are visible starting at the init() method of your
RequestProcessor instance, because it receives the ApplicationConfig
for this application module:
public void init(ActionServlet servlet, ApplicationConfig appConfig)
throws ServletException {
MyControllerConfig myConfig = (MyControllerConfig)
appConfig.getControllerConfig();
if (myConfig.getFoo() != null) {
...
}
}
> 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
>
This particular kind of configuration doesn't fit the pattern of simple
JavaBean property setters as the customization mechanism. For 1.1
compatibility, your best shot is to parameterize a separate XML file that
defines your own configuration format (which, like every format, is
probably still fluid as well :-). In a post-1.1 release, we can look at
what's going on in the J2EE 1.4 world (using schemas for validation, and
namespaces for extensibility of deployment descriptors) as a model of how
to address this concern in a more general way.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
