gnodet wrote:
>
>
> What kind of use case do you have exactly ?
>
>
Listeners are not enough I think since it is based only on events. What
about "around" interceptors and eg. situation when you want to cancel some
exchange? My case is standard one. We have to proxy eg. jms bc (in fact it
is marshaller not the endpoint itself) in order to collect some metrics
(before and after). Every SU has dependencies to aopalliance, spring-aop,
aspectj, cglib etc. It is too much heavyweight. It seems to be trivial to me
to have feature like that:
<jms:consumer .... interceptor="#myLoggingInterceptor"/>
or even:
<jms:consumer .... advice="#myAdvice"/>
where myAdvice is pojo implementing some interface with chain of
interceptors within eg. Logging+Metrics
interceptor could have method with exchange as parameter. Turning aspects
on/off would be the
matter of commenting/uncommenting one attribute in endpoint. The aspect code
would be very lightweight not dependent to any API at all except eg. one
interface.
--
View this message in context:
http://www.nabble.com/Interceptors-like-functionality-tf4515215s12049.html#a12879640
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
