Rob,
I guess you already saw the previous thread about this, but in case you
didn't Olegs requirement for his bean factory are in the following messages:
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01763.html
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01724.html
Personally we extended ActionServlet for the following reasons:
1) To parse an additional XML configuration file and store the instantiated
objects in application scope.
2) To parse an additional XML file and use it to configure a framework built
on top of Struts.
3) Override the logging mechanism and add a "Console" window for testing
purposes.
4) To override the processPopulate() method to handle dynamic properties -
although as someone recently pointed out it probably would have been better
to change Bean/Property utils instead - although this way I can use Struts
"out of the box" rather than actually modifying struts classes.
Perhaps processing configuration files should be dealt with separately with
some kind of DigesterFactory as I believe this is probably the most common
reason for extending ActionServlet - being able to just specify an input
stream, dtd file name, set of rules and any methods the digester is
configured packages everything nicely into a single object per config file.
It would also alow testing of these kinds of thing outside the servlet
environment - very handy.
Ron,
I liked your Extension/ExtensionServlet - obviously to satisfy everyone it
would have to be able to be registered at various points in ActionServlets
process() method as well as the init() (e.g. processPreprocess() and
processPopulate() methods).
One small comment - shouldn't you also override the destroy() method in
ActionServlet and iterate through destroy() methods in the Extensions (and
the same for reload() with reload() in the extension calling its
destroy/init methods)?
Niall
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 28 June 2001 20:50
> To: [EMAIL PROTECTED]
> Subject: Re: Extensions to Struts
>
>
>
> Note that the main motivation for the extensions package
> at the link below was to avoid having to always extend
> the ActionServlet.
> As far as altering the behavior of things
> like the action classes, forwards, etc.. I think a good
> event/listener model could be used for most of those cases.
> I think that the event/listener registration could
> neatly be tied into the extensions package. You would
> create your org.strutsx.extensions.Extension subclass,
> and register for all of the events you are interested in
> there.
>
> --Ron
>
> Ted Husted writes:
>
> > Rob,
> >
> > If you have a chance take at look at this
> >
> > < http://www.rpsenterprises.com/struts/index.html >
> >
> > and let us know what you think.
> >
> > I agree that is very important that we look for ways for people to add
> > new functionality without subclassing everything in sight.
> >
> > "Leland, Rob" wrote:
> > >
> > > It would be nice if struts could be extended
> > > without having to place new code under
> > > the org.apache.struts.action classes,
> > > but just by dropping a separate jar file
> > > under some directory that would self-register.
> > >
> > > So what is the best way to extend struts
> > > so that it stays lean ?
> > >
> >
> > < ... />
>
