Return-Path: 
 <dev-return-13853-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org>
Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org
Received: (qmail 9558 invoked from network); 3 Sep 2007 07:19:41 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 3 Sep 2007 07:19:41 -0000
Received: (qmail 18453 invoked by uid 500); 3 Sep 2007 07:19:35 -0000
Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org
Received: (qmail 18429 invoked by uid 500); 3 Sep 2007 07:19:35 -0000
Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:dev@jackrabbit.apache.org>
List-Id: <dev.jackrabbit.apache.org>
Reply-To: dev@jackrabbit.apache.org
Delivered-To: mailing list dev@jackrabbit.apache.org
Received: (qmail 18420 invoked by uid 99); 3 Sep 2007 07:19:35 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Sep 2007 00:19:35 -0700
X-ASF-Spam-Status: No, hits=-100.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Sep 2007 07:19:39 +0000
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 819FC71420B
	for <dev@jackrabbit.apache.org>; Mon,  3 Sep 2007 00:19:19 -0700 (PDT)
Message-ID: <8831603.1188803959528.JavaMail.jira@brutus>
Date: Mon, 3 Sep 2007 00:19:19 -0700 (PDT)
From: "Ard Schrijvers (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1079) Extend the IndexingConfiguration to
 allow configuration of reuseable analyzers
In-Reply-To: <16833397.1187859030703.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org


    [ https://issues.apache.org/jira/browse/JCR-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524452 ] 

Ard Schrijvers commented on JCR-1079:
-------------------------------------

>no, I think it's better to have it symmetric. If they can only be used globally then you should only be allowed to configure them globally.

Also IMO this is best, because it might be very confusing. The reason why it can be only globally configured is in the tokenStream part of the analyzer:

public TokenStream tokenStream(String fieldName, Reader reader) {

This one is used for indexing *and* parsing for searching, and the only thing I can distinguish on is the String fieldName (string representation of the QName). There is no way to know which indexing-rule it holds for, hence, the global configuration. 



> Extend the IndexingConfiguration to allow configuration of reuseable analyzers
> ------------------------------------------------------------------------------
>
>                 Key: JCR-1079
>                 URL: https://issues.apache.org/jira/browse/JCR-1079
>             Project: Jackrabbit
>          Issue Type: New Feature
>    Affects Versions: 1.3.1
>            Reporter: Ard Schrijvers
>            Priority: Minor
>             Fix For: 1.4
>
>
> To the indexing_configuration.xml a xml block of analyzers should be configurable. In each <index-rule> to a property an analyzer can be assigned. This means, that property will be analyzed with that specific analyzer. In the first place, it enables multilingual indexing. 
> Documentation needs to be added explaining the difference in searching in the node scope [jcr:contains(.,'foo')] and in some property [jcr:contains(@myprop,'foo')]. The node scope will always be searched and indexed with the default analyzer, which can be configured in the workspace.xml in  the  <SearchIndex> element.
> Below a possible indexing_configuration.xml snippet is shown. Also node the possible enhancement (not sure wether this implementation will have it, because it requires a lot of filter Factories and is probably out of scope). Adding custom filters which do not need a factory might be easier.
> <analyzers>
> 	<analyzer name="fr" class="org.apache.lucene.analysis.fr.FrenchAnalyzer"/>
> 	<analyzer name="de" class="org.apache.lucene.analysis.de.GermanAnalyzer"/>
>         <analyzer name="compound" class="org.apache.lucene.analysis.SimpleAnalyzer">
>              <filter class="jr.StopFilterFactory" words="stopwords.txt"/>
>              <filter class="jr.EdgeNGramTokenizerFactory" side="front" minGram="1" maxGram="2"/>
>         </analyzer>
> </analyzers>
> <index-rule nodeType="nt:unstructured">
>        <property analyzer="fr">bode_fr</property>
>        <property analyzer="de">bode_de</property>
> </index-rule>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.