Hi Freeman, Le 09/05/2012 14:34, Freeman Fang a écrit : > > On 2012-5-9, at 下午5:09, Jerome Revillard wrote: > >> Hi, >> >> Thanks for the quick answer. >> >> If the problem is that an exception is raised before the Output >> interceptor >> is called, shouldn't it be handled by the "handleFault()" function? > No, handleFault() get invoked by unwind the interceptor chain, that's > said, all interceptors that get invoked already get chance to do the > clean up job in handleFault. > Let's say out interceptor chain has > Interceptor1==> Interceptor2====>Interceptor3 > If something wrong in Interceptor2, then will unwind the interceptor > chain, which means the handleFault() in Interceptor2 get invoked, > then the handleFault() in Interceptor1 get invoked, the handleFault() > in Interceptor3 won't get invoked.
Ok, this is what I understood. In my case, if an exception is raised by one of the InInterceptor, after our interceptor then, with our code, the lock must be cleaned-up. What if an exception is raised by the service itself ? >> >> Can you explain a bit more please how to store the lock login into the >> Message ? > Re-think about it, message isn't the good place to store lock, you > should avoid writing the lock yourself. If you wanna "lock" some > object during the web service operation, why not do it in serviceImpl > class directly? use some synchronized block or wait/notify pair should > be able to do this job, why you write the lock yourself? We are providing a kind of framework based on tomcat + cxf. Developers can create their own web service, which will be configured to use our interceptor. We provide some global context shared between all the web services and we have some cleanup process. This later must not occur in the middle of a web service call. We really want to be the less intrusive possible so we do not want the developers to modify their source code in order to be integrated. Putting this lock logic in the Interceptors seems to be a good idea in this context. Best, Jerome > > Freeman > > >> >> Best, >> Jerome >> >> -- >> View this message in context: >> http://cxf.547215.n5.nabble.com/Interceptors-behaviour-tp5696667p5696850.html >> Sent from the cxf-user mailing list archive at Nabble.com. > > --------------------------------------------- > Freeman Fang > > FuseSource > Email:[email protected] > Web: fusesource.com > Twitter: freemanfang > Blog: http://freemanfang.blogspot.com > http://blog.sina.com.cn/u/1473905042 > weibo: http://weibo.com/u/1473905042 >
smime.p7s
Description: Signature cryptographique S/MIME
