struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: initConfigDigester refactoring?
Date Mon, 15 Jul 2002 22:52:40 GMT


On Mon, 15 Jul 2002, Brian Topping wrote:

> Date: Mon, 15 Jul 2002 18:03:52 -0400
> From: Brian Topping <topping@digidemic.com>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: initConfigDigester refactoring?
>
> Hi all,
>
> I'm working on a servlet that was subclassed from ActionServlet 1.0, and
> trying to port it to 1.1.  I have most of the ActionServlet subclass
> reformulated as a subclass of RequestProcessor with the goal that the
> ActionServlet would not be impacted by the addition of this code.   In
> essence, I'm trying to leave ActionServlet untouched, then instantiate the
> RequestProcessor subclass through the Digester.
>
> Does this sound reasonable?
>
> My initial encouragement to go this route was provided by the Tiles example,
> but then I started to realize that even Tiles uses a subclass of
> ActionServlet.  I'd like to avoid that if possible.  It seems like
> ActionServlet.initConfigDigester() is the only bottleneck on that, and if it
> was refactored in a manner that would allow the ConfigRuleSet to be
> supplemented with additional rules via additional calls to
> Digester.addRuleSet(), the additional options required by custom
> RequestProcessors could be added without subclassing ActionServlet simply to
> override initConfigDigester.
>
> In my admittedly half-baked understanding of Struts, it seems like a
> hierarchical Digester model would allow the ActionMapping/ActionConfig class
> to control config processing customizations without changes to ActionServlet.
> In this manner, <action-mappings type="foo.bar"/> could be used, foo.bar
> would be delegated to in order to process the node tree underneath this
> action-mappings node.  Each action would then be given the option to name a
> RequestProcessor that it wanted to use, which
>
> But then, I presume that I am probably missing something big, and am missing
> other things.  If I can do this without any changes to Struts, that would be
> ideal.
>
> Any insights greatly appreciated.
>

Hi Brian,

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.

To do zero-modifications customized configuration like this, I'd consider
using servlet init parameters with a naming pattern that your request
processor implementation would know, and/or a plug-in whose properties can
be set with <set-property> elements, and whose init() method could store
itself someplace that the request processor would be able to find them.

> -b
>

Craig


> _________________________________________________________
> Freedom is tyranny as a happy lamb.
> Terrorism is freedom as a hungry wolf.
>          - Gene Kan
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message