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.
-b
_________________________________________________________
Freedom is tyranny as a happy lamb.
Terrorism is freedom as a hungry wolf.
- Gene Kan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
