interceptor-set ( id=AnInterceptorSet ) {
apply-to ( service-id=com.foo.a-module.* )
apply-to ( service-id=com.foo.another-module.AnotherService )
interceptor ( service-id=AnInterceptor )
interceptor (service-id=AnotherInterceptor )
}
I think that dividing this in two would be nice... so we could reuse the interceptor stack definition.
For instance:
interceptor-set ( id=AnInterceptorSet ) {
interceptor ( service-id=AnInterceptor )
interceptor ( service-id=AnotherInterceptor )
}
interceptor-point ( id=AnInterceptorPoint interceptor-set=AnInterceptorSet ) {
intercept ( service-id=com.foo.a-module.* )
intercept ( service-id=com.foo.another-module.AnotherService )
}
Also giving the option in <interceptor-apply> of specifying an interceptor-set or a single interceptor service would be nice, but should be mutually exclusive.
Possibly off topic from here ---------------
All of this reminds me an old thorn I have with interceptor stuff in HiveMind... I think HiveMind might support interceptors defined at method level, and this interceptor-apply thing might definitely make this possible... thus simplifying much of the interceptor service implementation.
For example:
-- Java --
public interface MethodInterceptor {
public void interceptCall(Object[] args, ....);
}
-- SDL --
service-point ( id=AMethodInterceptor ) {
create-instance ( class=AMethodInterceptorImpl )
}
method-interceptor-set ( id=AnInterceptorSet ) {
method-interceptor ( service-id=AMethodInterceptor )
.
.
}
method-interceptor-point ( id=AMethodInterceptorPoint interceptor-set=AnInterceptorSet ) {
intercept-method ( _expression_="*.create*()" )
intercept-method ( _expression_="com.foo.*.create*()" )
}
With something like this, method interceptor implementations could be really easy and fast to write... no need to juggle with byte code generation, or, when interested in intercepting a single method no need to generate pass through implementations for all others.
Wouldn't this be sweet?
Opinions?
El jue, 29-07-2004 a las 12:21, Howard Lewis Ship escribió:
I've been thinkikng in terms of a new element, interceptor-set, that
would use various rules (i.e., regular _expression_ matching) to
determine which services would be interceptored, and then use standard
<interceptor> elements to add those interceptors. This would be much
more in line with an AspectJ style pointcut.
On Thu, 29 Jul 2004 08:56:58 -0400, James Carman
<[EMAIL PROTECTED]> wrote:
>
> Ahhh, yes! I see what you mean. What I had in mind was something like
> this...
>
> interceptor-chain (id="standard-interceptors")
> {
> interceptor (service-id="hivemind.LoggingInterceptor")
> interceptor (service-id="somemodule.SecurityInterceptor")
> }
>
> implementation (service-id="MyService")
> {
> interceptor (chain-id="standard-interceptors")
> }
>
> I am not sure that's the best syntax, but you get the idea. This way, I can
> save some typing (the more interceptors, the more you save, obviously). It
> could also be used in conjunction with your idea! You could inject an
> interceptor chain into a group of services, identified using some form of
> regular expressions like you propose!
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 26, 2004 1:50 PM
> To: [email protected]
> Subject: RE: service for interceptor configuration
>
> James,
>
> > Maybe I didn't word my question very well, but I think we
> > are both talking about the same thing. That's what I was
> > trying to find out. I think what you're suggesting is that
> > we have a way of defining a reusable list of interceptors
> > that can be applied to multiple services as a whole, rather
> > than having to re-define the entire list for all the services.
> > Is that what you want?
>
> I think we are talking about slightly different things here. Let's take
> a look at a more comprehensive example. Imagine a module with the
> following descriptor:
>
> module (id=com.foo version="1.0.0")
> {
> service-point (id=A interface=com.foo.A)
> {
> invoke-factory (...) {...}
> }
> service-point (id=B interface=com.foo.B)
> {
> invoke-factory (...) {...}
> }
> }
>
> Now I'd like to apply the same interceptor (e.g. the
> hivemind.LoggingInterceptor) to both of the declared services. I could
> do this in the same module or a different module. Irrespectively it'd
> go something like this:
>
> implementation (service-id=com.foo.A)
> {
> interceptor (service-id=hivemind.LoggingInterceptor)
> }
> implementation (service-id=com.foo.B)
> {
> interceptor (service-id=hivemind.LoggingInterceptor)
> }
>
> What I was suggesting was that the above two declarations could be
> replaced by the following:
>
> contribution (configuation-id=InterceptorInjections)
> {
> injection (interceptor=hivemind.LoggingInterceptor
> services=com.foo.*)
> }
>
> The configuration contributed to would be used by the suggested service,
> let's call it InterceptorInjector, to apply the
> hivemind.LoggingInterceptor to every service in the com.foo module. I
> used a pattern to select the services which the interceptor should be
> applied to, which is very primitive, but maybe it's good enough.
>
> The InterceptorInjector service could of course also be used with
> predefined lists of interceptors, which seems to be what you are talking
> about.
>
> Hope this example makes things clearer.
>
> --knut
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-- Pablo I. Lalloni <[EMAIL PROTECTED]> Teléfono +54 (11) 4347-3177 Proyecto Pampa Dirección Informática Tributaria AFIP > In 2010, M$ Windows will be a quantum processing emulation layer for a > 128-bit mod of a 64-bit hack of a 32-bit patch to a 16-bit GUI for an > 8-bit operating system written for a 4-bit processor from a 2-bit > company that can't stand 1 bit of competition. |
