Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <79986273.39001267471325878.JavaMail.jira@brutus.apache.org>
Date: Mon, 1 Mar 2010 19:22:05 +0000 (UTC)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Updated: (LUCENE-2154) Need a clean way for Dir/MultiReader
 to "merge" the AttributeSources of the sub-readers
In-Reply-To: <377230757.1260563538136.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LUCENE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated LUCENE-2154:
----------------------------------

    Attachment: LUCENE-2154-Jakarta-BCEL.patch

Here the third incarnation of the patch. A little bit more complicated, because directly assemblying bytecode, but much cleaner and without strange parsers. It uses Jakarta BCEL, which is e.g. also used by Apache XALAN XSLTC, and its even included in JDK5 (somehow inofficial in renamed com.sun.internal packages).

The approach is the same as with JavAssist, but has several advantages:
- The typing is hard, so all bytecode is generated using real Type classes, retrieved from reflection analysis of the Attribute-Interface to proxy. The method signature is copied.
- It will not likely break with later VDKs if the class format changes again. The Problem with JavAssist is, that it loads the interface and implementation classes from the bytecode and must analyze it. If we get Java 7 and a new classformat, this will likely break (as e.g. classes loaded from rt.jar may not be analyzed). The BCEL approach does not use loading classes in bytecode, it just uses reflection to generate the proxy method signatures and inserts the byte code to delegate to the delegate.
- The generated class is not loaded by a hack, but instead a delegating ClassLoader is dynamically created to load the class into the JVM. The classloader delegates all other requests to the proxied Attribute's classloader.

By the way, XALAN is bundling BCEL, in old version, but under the original package names, which may lead to conflics when also bundling in lucene. I would prefer to import the whole source (in parts) like automaton was put into o.a.l.util. But that only, if we really want to do it like this way. But I still think for some TokenStreams this would be a real speed improvement, so we can also make a contrib package out of it.

> Need a clean way for Dir/MultiReader to "merge" the AttributeSources of the sub-readers
> ---------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2154
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2154
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: Flex Branch
>            Reporter: Michael McCandless
>             Fix For: Flex Branch
>
>         Attachments: LUCENE-2154-cglib.patch, LUCENE-2154-Jakarta-BCEL.patch, LUCENE-2154-javassist.patch, LUCENE-2154-javassist.patch, LUCENE-2154.patch, LUCENE-2154.patch
>
>
> The flex API allows extensibility at the Fields/Terms/Docs/PositionsEnum levels, for a codec to set custom attrs.
> But, it's currently broken for Dir/MultiReader, which must somehow share attrs across all the sub-readers.  Somehow we must make a single attr source, and tell each sub-reader's enum to use that instead of creating its own.  Hopefully Uwe can work some magic here :)

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


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org