I really think that having something like the MethodInterceptor is really needed... of course, it could be implemented as an InterceptorFactory (as today's) that accepts pairs of method-matcher expressions and method interceptor service-points as its parameters-schema and then produce an Interceptor that makes the appropriate calls...
implementation ( ... ) {
interceptor ( service-id=MethodInterceptor ) {
method ( name="create|update|remove" service-id=some.MethodInterceptorService )
method ( name="find*" service-id=some.OtherMethodInterceptorService )
}
}
Here it appears to me the fact that it will be needed the posibility of specifying some parameters in the body of every method element. This would be something like:
implementation ( ... ) {
interceptor ( service-id=MethodInterceptor ) {
method ( name="create|update|remove" service-id=some.package.TransactionInterceptorService ) {
policy ( name=required )
}
method ( name="find*" service-id=some.package.TransactionInterceptorService ) {
policy ( name=supports )
}
}
}
What's inside method element's body should be specifyied in the proper method interceptor service's parameters schema.
Also, we should not forget the interceptor-set stuff as it would let us write sooo much less descriptor stuff...
What d'you think?
Ahh!.. If I just had the time for implementing this...
Pablo.-
PS: mmm... I should be getting rid of thinking in SDL, ain't I?
El vie, 20-08-2004 a las 10:29, James Carman escribió:
I would agree with that. The only thing I don't like about the current implementation is that you have to actually WRITE a class to plug in an interceptor. However, it would be rather trivial to change the implementation of MethodInterceptorFactory to have a writeable property of type MethodInterceptor and we could inject some service that implements that interface (I believe this was already discussed/suggested). Any other suggestions on how we could make it easy to "plugin" a MethodInterceptor with no coding required? -----Original Message----- From: Marcus Brito [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 9:09 AM To: [email protected]; Howard Lewis Ship Subject: Re: [VOTE] Release HiveMind 1.0-rc-1 There's one last thing that I'd love to see in hivemind before it goes final, and it's HIVEMIND-45, aopalliance support. Why is that? Hivemind will be a new product out there, and people will ask two things: 1) What hivemind brings to the table that I don't have already? 2) Can I leverage my existing code to work with hivemind? I'll leave 1) as a reader's exercise, but HIVEMIND-45 would help a lot with 2). I imagine hivemind could use all the nifty spring interceptors people are writing for spring out there -- and it would be great if we could tell them "hey, you can use this interceptor with hivemind too". -- Marcus On Fri, 20 Aug 2004 08:59:29 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > All outstanding bugs (not feature requests) have been fixed. The code > looks rock solid. The documentation is there. It's time to go forward > and get a 1.0 release out to the world. > > Howard Lewis Ship: +1 (binding) > > Note: your vote is binding only if you are a HiveMind committer. > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > http://howardlewisship.com > > --------------------------------------------------------------------- > 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. |
