struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Smith <ron.sm...@rpsenterprises.com>
Subject Re: About extensons support mechanism...
Date Wed, 04 Jul 2001 13:18:23 GMT

When I created the ExtensionsServlet (I assume ServicesServlet
takes its place here), I stopped short after the
init(), destroy(), and initDigester() methods because I had
a feeling that we might want to handle extending the other
methods using a different mechanism.
I see init, destroy, and initDigester methods as basic
lifecycle methods that most/all extensions/services would want
to tap into.
When getting into the process() type of methods, I could see
many extensions would want to tap into one or more of these methods,
but why limit it to the ActionServlet class?  An extension may want
to be able to tap into points in processing of other classes, such
as an action class or forward class.  From looking at the code it seems
like most processing is going on in the ActionServlet, but
my gut feel is that some extensions will need to extend processing
points in other classes besides ActionServlet - it's just one class
in an application framework after all.

For this, I think something like your second solution with a more
centralized event dispatcher/queue would be needed.  The listeners
(services) would register interest in an event with a central
dispatcher.  When the ActionServlet (or whatever class is generating
the events) gets to one of these points in processing, like
processPopulateBefore(), it would fire off an event to the central
dispatcher which would immediately notify the listeners registered
for that event type.
So the listeners are decoupled from the class generating the
events (e.g. ActionServlet).  Heck, the object generating the
event doesn't even have to exist for the listener to be able to
register interest in the event it generates (which is probably necessary
to trap events from classes like Action and ActionForward).

Is what I describe above within the scope of the event/listener
todo for 1.1?  I thought it might be, which is why I said
I was interested in tying the Extensions package into
the event/listener model work.

So my two cents is I'd like to generalize the listener/event/dispatch
mechanism and to support listening to classes beyond ActionServlet.


Oleg V Alexeev wrote:
> 
> Hello struts-dev,
> 
>   This evening I end up druft of ServicesServlet - extended version of
>   ActionServlet with support of pluggable services (extensions in old
>   terms). I puzzle over architectural question about ServicesServlet
>   and may be anybody can suggest me right way...
> 
>   ServiceServlet work on idea - developer can register unlimited
>   number of services in struts-config, each service is a java class
>   based on Service interface, each service can be subscribed to any
>   processing point, such as - init, destroy, initDigester,
>   processPreprocess, processPopulateBefore, processPopulateAfter,
>   processValidateBefore, processValidateAfter. ServiceServlet iterate
>   via list of subscriptions at every processing point and call
>   appropriate method from service.
> 
>   My question is - what way is the best to serve processing points
>   listed above? Now I create FastArrayList instances for every
>   subscription list and all manipulations with subscriptions
>   (register, get iterator via subscriptions, drop, etc.) are made with
>   help of separate method -
> 
>    registerInitMember( Service service, int order ) {}
>    regisetrInitDigesterMember( Service service, int order ) {}
>    ....
> 
>   May be such solution would be more flexible? -
>    registerMember( Service service, int order, String pointName ) {
>          //find ArrayList of subscriptions for such pointName
>          //register service at ArrayList
>    }
> 
>   Hard coded solution is more reliable, but time consume and not
>   flexible. But more flexible solution, with search for appropriate
>   subscription, is slow for my mind. What way is the best?
> 
> 
> --
> Best regards,
>  Oleg                          mailto:gonza@penza.net

Mime
View raw message