jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: problem with index not being updated
Date Fri, 13 Jan 2006 11:12:49 GMT
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

Mime
View raw message