On 1/12/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote: > > 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 > >
in fact, i make the repository available to the cosmo webapp as a tomcat naming resource. this has already caused classloading issues with this text filter, as cyrus daboo (the author) described in this thread: <http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/4509> it may be that cyrus' TextFilterFactory approach causes the classloading problem i'm seeing, but i can't say for sure, because to be honest, classloading makes my head spin :) what do you think? and for the record, what is the "canonical" way to register a custom filter with jackrabbit?
