Blah, this is going to bite me when I upgrade next. I'm currently working around it with a patch I have to turn off post commit listeners as I haven't rolled to the version that extended the API with the requiresPostCommitHanding method which should allow me to get rid of my last local patch.
The nice piece with the post event listeners is that you have entity state automatically passed so if you need to do something specific with them (like update a Quartz schedule) then you can.
I see 2 ways to fix this always fire behaviour.
1) Don't fire the event listeners at all from the actions events themselves under a failure condition. This may trip up users that hacked their way around the missing success/failure if they still wanted to do something under the failure condition. I'd be ok with this from a selfish standpoint as I currently only need to suppress them under the failure.
2) Modify the API to pass the success state through. This has a few issues a)it's an API change on an interface so could effect extensions by users. b) the PostUpdate/Insert/Delete listener interefaces are shared between the PostX and PostCommitX events where I don't know if it makes sense to have a success/fail in the non commit scenario.
If anyone from the dev team has a preference pipe up and I can implement and submit a pull request 'soonish'. I don't think it's a whole lot of effort to implement. I'll be looking to do something locally regardless and I'm really trying to get back to a vanilla release w/o any patches.
|