But this kind of feature can not easily be generic.  It would be
specific for each kind of endpoints I suppose.  Just to understand
your use case a bit more, what do you want to do with messages that
you don't want to process ? Just discard them ? Then you could use a
filter (and use the route transformation layer i've just talked about
maybe) or even use a camel filter which is really easy to set up.
Also note that in the OSGi way, the whole classloader architecture is
different and you can easily share libraries between JBI applications
(you're not limited anymore to jars included in the SU).  Even with
3.2, you can already add a SL to a SU classloader.

On 9/25/07, Przemyslaw Budzik <[EMAIL PROTECTED]> wrote:
>
>
>
> 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.
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Reply via email to