Brian Moseley wrote:
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>
oh, I completely forgot to reply to this message, I apologize.
the approach certainly works. as a quick recap here: the text filter is
added to jackrabbit from within the web application that uses a
different classloader than the one jackrabbit is using for its classes.
I suggest to move your text filter implementation to the same class path
where the jackrabbit classes are located. and then configure the text
filter in repository.xml and workspace.xml. this will most probably
solve the ThreadDeath issue you see. with your current setup, jackrabbit
as a resource depends on a webapp classloader that is marked invalid at
some point (cosmo reloads) and will never recover. moving the text
filter class to jackrabbits classloader will avoid this dependency.
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?
yeah, classloading is not trivial stuff. I really suggest to move the
text filter class. Or is there a specific reason why you want to keep
the classes in the webapp?
and for the record, what is the "canonical" way to register a custom
filter with jackrabbit?
the official way is to configure the filter in repository.xml and/or
workspace.xml. See: http://issues.apache.org/jira/browse/JCR-265
regards
marcel
