Hi Marcel,
--On November 22, 2005 4:13:46 PM +0100 Marcel Reutegger
<[EMAIL PROTECTED]> wrote:
Also some time ago I did a filter for handling RTF files. It uses
HTMLEditorKit JFC classes. I could contribute it if you find interesting.
sure, we are always interested in new filters.
I recently implemented a text/calendar filter for handling iCalendar data.
However, because the filter depends on calendar libraries specific to the
webapp, and because it is doing some special indexing to aid CalDAV query
reports, I wanted the filter to be part of the webapp rather than core
jackrabbit. This posed a problem with the Tomcat class loader.
In Tomcat, the jackrabbit core jar file is part of Tomcat's 'common'
libraries and there is a class loader associated with that. Webapps have
their own class loaders associated with them, and those are 'lower' in the
class loader hierarchy than the 'common' class loader. As a result, the
jackrabbit core classes were unable to dynamically find and load a class
from the webapp using e.g. Class.forName().
To get around this I developed a TextFilterFactory class for jackrabbit
core that allows for adding TextFilter classes after the initial static
initialization from the repository.xml file. Now my webapp can load its own
TextCalendarTextFilter class into the indexer when it is initialized and
jackrabbit will use that for the appropriate data as it arrives.
This new approach may or may not be of interest to others. If it is then I
can send in the patches.
Note that the class loader problem occurs in several other cases as well.
In fact any attempt to override the default classes in a repository.xml
file with webapp specific classes would fail. Perhaps there is a way to
solve the class loader problem directly? If not, then it might make sense
to look into using more 'factory' type classes to aid with loading webapp
specific classes.
--
Cyrus Daboo
