lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-2154) Need a clean way for Dir/MultiReader to "merge" the AttributeSources of the sub-readers
Date Mon, 01 Mar 2010 19:22:05 GMT

     [ 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


Mime
View raw message