struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg V Alexeev <>
Subject Re[2]: About extensons support mechanism...
Date Sun, 08 Jul 2001 10:09:57 GMT
Hello Martin,

Sunday, July 08, 2001, 4:55:56 AM, you wrote:

>> 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.

MC> I think this is a perfect candidate for the event/listener framework. The
MC> key is to decide what the interesting events are. This needs to be done
MC> outside the context of the current implementation as much as possible.

MC> What I mean by that is that we should not be looking at the code and saying
MC> "oh, there's an interesting method I'd like to hook into" so much as
MC> thinking "ah, it would be interesting to be told when this is about to
MC> happen or that has finished happening". If the code ends up needing some
MC> restructuring to accommodate that, then we should go ahead and make those
MC> changes.

MC> If we only look at the current implementation, then we will be looking with
MC> blinders on. There is a much greater risk that we will hinder the
MC> development of later extensions, by looking at what we have instead of
MC> thinking about what we really want.

Yes. Now I try implement first edition of such ServicesServlet in base
of ActionServlet code and insert calls to the Services to the main
(for my mind) processing points. I not venture to make core
refactoring of ActionServlet - I only insert calls to the external
services to the processPreprocess(), processValidate(), etc.

MC> --
MC> Martin Cooper

MC> ----- Original Message -----
MC> From: "Ron Smith" <>
MC> To: <>
MC> Sent: Wednesday, July 04, 2001 6:18 AM
MC> Subject: Re: About extensons support mechanism...

>> 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                

Best regards,

View raw message