Brian Moseley wrote:
let me give you a second example. that ThreadDeath we're talking about in another list thread - that occurred in my custom text filter as well. it didn't cause the server to crash or even for the webdav request to fail. in fact, the PUT succeeded, but there was no indication to the user that the text filter had failed and that the event he just uploaded was not in fact indexed and would not be included in subsequent queries. so even though we had the ThreadDeath stack trace in the error log, we spent most of a day putting two and two together to figure out what was going on. it would have been more correct and informative for the filter to have vetoed the request or otherwise informed the jcr client layer that something went really wrong down below, so that i could have returned an error for the PUT, and it would have saved me time diagnosing the issue. does that make sense?
yes it does, and I think JCR-299 you created is a good way to address this issue.
so you're saying that even when you implement vetoable listeners, text filters won't be vetoable? you'll continue to just log and swallow potentially very important exceptions that might arise within filters due to circumstances you can't foresee?
filters are allowed to throw a RepositoryException, those are only logged and will not harm index integrity. and yes, I think this should stay as it is. unchecked exceptions or even errors are a different story and need to be handled. this is currently not the case.
if errors were handled properly with a transaction rollback, text filter developers will be able to abuse this and throw an unchecked exception, which would then trigger a rollback of the transaction. so, in the end you will still get vetoable text filters ;)
but that needs more thinking how this is handled deep inside jackrabbit. regards marcel
