jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject Re: problem with index not being updated
Date Thu, 12 Jan 2006 23:19:27 GMT
On 1/12/06, Marcel Reutegger <marcel.reutegger@gmx.net> 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?

View raw message