Konstantin, On 1/5/13 6:31 PM, Konstantin Kolinko wrote: > 2013/1/6 Christopher Schultz <ch...@christopherschultz.net>: >> >> On 1/5/13 12:52 PM, Konstantin Kolinko wrote: >>> 2) Calling PreDestroy methods if init() method fails. >>> >>> The specs say that >>> - if @PostConstruct methods fail then nothing is called afterwards, and >>> - if init() fails then destroy() is not called. >>> >>> I wonder whether failure of init() precludes @PreDestroy methods from >>> being called. The current implementation is that they are not called. >>> >>> I feel some concern as JSR250 and Servlet API are different APIs, and >>> in view of r1429173 which fixed a similar issue with cache in >>> SecurityUtil. >> >> I would be surprised to have PreDestroy called if destroy wasn't >> ultimately going to be called (or at least the goal is to call destroy >> -- perhaps some error prevents us from doing so). I guess that means >> that I would personally favor the current implementation. On the other >> hand, I don't use these features so I don't have a vested interest (yet) >> in how they operate. I'm just commenting based upon basic logic. >> > > I have a slight guess that you were confused by the names. It is > called "Pre" destroy, but it is actually called after the destroy > method. The order of calls is: > > (1) @PostConstruct > (2) init() > ... > (3) destroy() > (4) @PreDestroy > > In the Servlet spec it is explicitly mentioned that methods annotated > as PostConstruct are called before any lifecycle methods. There is no > such clarity regarding the PreDestroy methods, but the above order > comes from the symmetry and it is how the current implementation is.
Right: this also mirrors the (somewhat confusing) ServletContextListener method "contextDestroyed" which actually gets called /before/ the context is destroyed. My argument still holds: if destroy() isn't called, @PreDestroy should also not be called IMO (regardless of the order). -chris
signature.asc
Description: OpenPGP digital signature
