Brian Moseley wrote:
On 1/11/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
hmm, that is pretty strange. a ThreadDeath is only thrown when the
thread is stopped with Thread.stop(). the query handler does not catch
any errors. If a ThreadDeath can happen during regular operation I need
to change the query handler to be able to deal with such a situation.
i see them all the time with tomcat, after i've reloaded a web
application several times during a development cycle. there's a lot of
discussion about it on the tomcat list and others. something about
memory leaks and classloaders. i haven't paid that much attention
because the proposed fixes never work for me ;)
that doesn't surprise me. all that talking about log4j and copying and
moving jars around will never solve the issue [1]. brett randall seems
the only one who knows what's going one but no one is paying attention
to him.
to me this is a clear misuse of the ThreadDeath error in tomcats
WebappClassLoader.
also relates to classloader issue we already had with tomcat on
shutdown: [2]
after some thinking I suggest you try to pre-load the classes for your
text filter to avoid access to tomcats WebappClassLoader when cosmo is
reloaded. but that will probably shift the problem to another area
because it does not really solve the problem but only provides a workaround.
or as an alternative you could try to separate the repository from cosmo
and run jackrabbit in a separate webapplication. that way a reload of
cosmo will not cause a shutdown of the repository and your text filter
class is not in the same classpath as cosmo.
regards
marcel
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=26372
[2] http://issues.apache.org/jira/browse/JCR-120
