[
https://issues.apache.org/jira/browse/LUCENE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794799#action_12794799
]
Uwe Schindler edited comment on LUCENE-2182 at 12/28/09 10:56 AM:
------------------------------------------------------------------
Shalin:
If you use the new AttributeSource API for TokenStreams and define an own
attribute (like the person did), you have to define two classes, see:
[http://lucene.apache.org/java/3_0_0/api/core/org/apache/lucene/analysis/package-summary.html]
-> New TokenStream API -> defining own attribute.
You define an interface for your attribute and also define an implementation
class. The TokenStream will call addAttribute(CustomAttribute.class) and the
default attribute factory inside Lucene will then load the "default"
implementation class "CustomAttributeImpl". This is done via reflection and
Class.forName.
If the interface is defined in an own Classloader (like the interface and impl
is put into the solr plugins folder), the interface itsself is loaded correctly
(because instantiated by the plugin's tokenstream code). But the code inside
AttributeSource then tries to load the Impl class with
forName(attributeClassName + "Impl"). As forName per default uses the
classloader from the calling class, this fails, because th classloader lucene
was loaded with does not know the plugins folder.
Therefore, the implementation class must be loaded with the same classloader as
the interface Class<? extends Attribute> object passed into addAttribute().
Thats not a failure of Solr, but it the mechanism prevents putting own
attribute impls into plugins of solr. They must be in the lib folder where
lucene-core.jar is. By this patch it is more consistent and enforces, that the
impl class comes from the same source as the base attribute.
was (Author: thetaphi):
Shalin:
If you use the new AttributeSource API for TokenStreams and define an own
attribute (like the person did), you have to define two classes, see:
[http://lucene.apache.org/java/3_0_0/api/core/org/apache/lucene/analysis/package-summary.html]
-> New TokenStream API. You define an interface for your attribute and also
define an implementation class. The default in Lucene is that the TokenStream
will call addAttribute(CustomAttribute.class) and the default loader in Lucene
will load the "default" implementation class "CustomAttributeImpl". This is
done via reflection and Class.forName. If the interface is defined in an own
Classloader (like the interface and impl is put into the solr plugins folder),
the interface is loaded correctly (because instantiated by the plugin's
tokenstream code). But the code inside the AttributeSource then tries to load
the Impl class with forName(attribueClassName + "Impl"). As forName per default
uses the classloader from the calling class, this fails, because th classloader
lucene was loaded with, does not know the plugins folder.
Therefore, the implementation class must be loaded with the same classloader as
the interface passed into addAttribute().
Thats not a failure of Solr, but it the mechanism prevents putting own
attribute impls into plugins of solr. They must be in the lib folder where
lucene-core.jar is. By this patch it is more consistent and enforces, that the
impl class comes from the same source as the base attribute.
> DEFAULT_ATTRIBUTE_FACTORY faills to load implementation class when iterface
> comes from different classloader
> ------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2182
> URL: https://issues.apache.org/jira/browse/LUCENE-2182
> Project: Lucene - Java
> Issue Type: Bug
> Components: Other
> Affects Versions: 2.9.1, 3.0
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 2.9.2, 3.0.1, 3.1
>
> Attachments: LUCENE-2182.patch
>
>
> This is a followup for
> [http://www.lucidimagination.com/search/document/1724fcb3712bafba/using_the_new_tokenizer_api_from_a_jar_file]:
> The DEFAULT_ATTRIBUTE_FACTORY should load the implementation class for a
> given attribute interface from the same classloader like the attribute
> interface. The current code loads it from the classloader of the
> lucene-core.jar file. In solr this fails when the interface is in a JAR file
> coming from the plugins folder.
> The interface is loaded correctly, because the
> addAttribute(FooAttribute.class) loads the FooAttribute.class from the plugin
> code and this with success. But as addAttribute tries to load the class from
> its local lucene-core.jar classloader it will not find the attribute.
> The fix is to tell Class.forName to use the classloader of the corresponding
> interface, which is the correct way to handle it, as the impl and the
> attribute should always be in the same classloader and file.
> I hope I can somehow add a test for that.
--
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: [email protected]
For additional commands, e-mail: [email protected]
