struts-dev mailing list archives

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

Sunday, July 08, 2001, 12:37:37 AM, you wrote:

CRM> Several intermixed comments, plus some general notes at the bottom ...

CRM> On 5 Jul 2001, Roland Huss wrote:

>> Oleg V Alexeev <> writes:
>> >   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.
>> Instead of a "Service" _interface_ I suggest a a Service base class
>> with no-op implementations for the plugin hooks. This would make a
>> possible late upgrade of the plugin contract much easier, since it
>> won't break existing code.

CRM> +1, *especially* if you use the "hard coded" registration
CRM> approach.  Otherwise, you'll break every Service implementation in the
CRM> world when you add a new registration hook.  This is why ActionForm is a
CRM> base class rather than an interface.

Ok, I agree with you. But if we place hard-coded calls to the services
methods to the ActionSertvlet then we lose ability to pick out
Services support mechanism from ActionServlet.

CRM> An intermediate solution would be to define Service as an interface and
CRM> ServiceBase (or something) as a convenience base class that most people
CRM> would use.  That way, you only impact those who directly implement Service
CRM> themselves.

Now I implement Service as base abstract class with mandatory methods
- init(), destroy().

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

CRM> Both patterns are common in JavaBeans APIs, but I tend to slightly prefer
CRM> the "hard coded" approach myself.  Among other things, it eliminates the
CRM> chance to have typos in your pointName values, leading to "why didn't my
CRM> service get invoked?" kinds of questions.

It is main problem for me now... I trying to hide all complex logic in
ServicesManager and in Service base class.

CRM> Do you really need an "order" argument, though?  If we guaranteed that
CRM> services would be invoked in the order that they are listed in the
CRM> struts-config.xml file, that would seem to give people the control they
CRM> need.

Why not? Sometimes we need to define order of calls to the services
because of each service can change data in request or session scope
(references to this objects can be passed to the service methods
calls) and order of such data changing is application specific, of

>> I think the first solution is more preferable, since you have only one
>> kind of plugin defined by one interface (or base class).
>> If you would like to differentiate between different kind of plugins
>> different kind of interfaces (or base classes) like InitService and
>> ProcessService might provide the extra flexibility to selectively call
>> only the appropriate plugin at certain hooks (and a plugin only needs
>> to implement the service interface (extend service base class) it is
>> interested in. (Well, in this scenario, interfaces are probably better
>> suited than base classes, since a plugin could implement several
>> interfaces at once but not extend more than one base class).

CRM> On a more general note, there is a "services framework" type thing in
CRM> several other projects, notably in Turbine and Cocoon (and
CRM> Jetspeed?).  Can we leverage/learn anything from those efforts?  Is there
CRM> any opportunity to abstract out common requirements in a
CRM> framework-independent manner that could be shared (perhaps as a Commons
CRM> project)?

Yes, now I base my work on idea of "services framework"... 8)) And try
to isolate ServicesManager logic from Struts framework.

Hm.. I forget another projects... 8) I'l take a look shortly...

Best regards,

View raw message