lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-5526) Query parser extends standard cause NPE on Solr startup
Date Tue, 21 Jan 2014 22:00:25 GMT


Hoss Man commented on SOLR-5526:

Hey Vitaliy,

For the most part, these tests look great -- just a few minor things i think we should try
to clean up...

* QParserPlugin.standardPlugins's javadoc needs to point out the importance of these names
being static & final so people aren't surprised by these  tests when new parsers are added
in the future.
* TestStandardQParsers is doing something sufficiently odd that it really needs some javadocs
explaining why it exists (ie: mention the class loading problems associated if there is a
standardPlugin that has a non-static, non-final name, with an {{@see}} this issue, {{@see
QParserPlugin.standardPlugins}}, etc...)
* we should probably make TestStandardQParsers assert that the static & final name it
finds in each class matches the name associated in QParserPlugin.standardPlugins.
* solrconfig-query-parser-init.xml has a cut & paste comment referring to an unrelated
* TestInitQParser should have a javadoc comment explaining what the point of the test is
* TestInitQParser should actaully do a query using the "fail" parser registered in the config,
to help future-proof us against someone unwittingly changing the test config in a way that
defeats the point of the test.

...if you want to take a crack at this that would be great, if not i'll try to make some time
later this week.

> Query parser extends standard cause NPE on Solr startup
> -------------------------------------------------------
>                 Key: SOLR-5526
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: query parsers
>    Affects Versions: 4.5.1, 4.6, 5.0
>         Environment: Linux, Java 1.7.0_45
>            Reporter: Nikolay Khitrin
>            Priority: Blocker
>         Attachments: NPE_load_trace, SOLR-5526-final-names.patch, SOLR-5526-final-names.patch,
SOLR-5526-tests.patch, SOLR-5526.patch, SOLR-5526.patch
> Adding any custom query parser extending standard one with non-final field {{NAME}} lead
to messy {{NullPointerException}} during Solr startup.
> Definition of standard parsers is located in  {{QParserPlugin.standardPlugins}} static
array. The array contains names from static {{NAME}} fields and classes for each plugin. 
> But all of listed parsers are derived from {{QParserPlugin}}, so we have circular dependency
of static fields.
> Normally, class loader start initializing {{QParserPlugin}} before all listed plugins
in {{SolrCore.initQParsers}}, and array elements referenced to {{NAME}} plugins' fields are
filled properly.
> Custom parsers are instantiated before standard parsers. And when we subclass plugin
with non-final {{NAME}} field and add it to Solr via {{solrconfig.xml}}, class loader start
loading our class before {{QParserPlugin}}. Because {{QParserPlugin}} is a superclass for
plugin, it must be initialized before subclasses, and static dereferencing cause null elements
in {{standardPlugins}} array because it filled before {{NAME}} field of loading plugin's superclass.
> How to reproduce:
> # Checkout Solr (trunk or stable)
> # Add the following line to solr/example/solr/collection1/conf/solrconfig.xml
>   {{<queryParser name="fail" class=""/>}}
> # Call ant run-example in solr folder
> Possible workarounds:
> * dev-workaround: add {{int workaround = QParserPlugin.standardPlugins.length;}} as a
first line to
>   {{SolrCore.initQParsers}}
> * user-workaround: add plugin with final {{NAME}} field (edismax) to solrconfig.xml 
before subclasses of standard plugins. 
>   {{<queryParser name="workaround" class=""/>}}
> Possible fix:
> Move {{standardPlugins}} to new final class to break circular dependency.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message