[jira] [Commented] (SOLR-12367) When adding a model referencing a non-existent feature the error message is very ambiguous
[
https://issues.apache.org/jira/browse/SOLR-12367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478639#comment-16478639
]
Georg Sorst commented on SOLR-12367:
I just noticed the same also happens when setting the weight of an (existing)
feature to an integer instead of a float, ie.
{{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
--data-binary '}}
{
{{ "class": "org.apache.solr.ltr.model.LinearModel",}}
{{ "name": "myModel",}}
{{ "features": [ \{"name": "whatever" }],}}
{{ "params": {"weights": {"whatever": 1
{{}' -H 'Content-type:application/json'}}
will also throw "Model type does not exist
{{org.apache.solr.ltr.model.LinearModel}}". If you change the weight to 1.0 it
will work fine (if the feature "whatever" exists).
> When adding a model referencing a non-existent feature the error message is
> very ambiguous
> --
>
> Key: SOLR-12367
> URL: https://issues.apache.org/jira/browse/SOLR-12367
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 7.3.1
>Reporter: Georg Sorst
>Priority: Minor
>
> When adding a model that references a non-existent feature a very ambiguous
> error message is thrown, something like "Model type does not exist
> org.apache.solr.ltr.model.{{LinearModel}}".
>
> To reproduce, do not add any features and just add a model, for example by
> doing this:
>
> {{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
> --data-binary '}}
> {
> {{ "class": "org.apache.solr.ltr.model.LinearModel",}}
> {{ "name": "myModel",}}
> {{ "features": [ \{"name": "whatever" }],}}
> {{ "params": {"weights": {"whatever": 1.0
> {{}' -H 'Content-type:application/json'}}
>
> The resulting error message "Model type does not exist
> {{org.apache.solr.ltr.model.LinearModel" is extremely misleading and cost me
> a while to figure out the actual cause.}}
>
> A more suitable error message should probably indicate the name of the
> missing feature that the model is trying to reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12367) When adding a model referencing a non-existent feature the error message is very ambiguous
[
https://issues.apache.org/jira/browse/SOLR-12367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-12367:
---
Description:
When adding a model that references a non-existent feature a very ambiguous
error message is thrown, something like "Model type does not exist
org.apache.solr.ltr.model.{{LinearModel}}".
To reproduce, do not add any features and just add a model, for example by
doing this:
{{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
--data-binary '}}
{
{{ "class": "org.apache.solr.ltr.model.LinearModel",}}
{{ "name": "myModel",}}
{{ "features": [ \{"name": "whatever" }],}}
{{ "params": {"weights": {"whatever": 1.0
{{}' -H 'Content-type:application/json'}}
The resulting error message "Model type does not exist
{{org.apache.solr.ltr.model.LinearModel" is extremely misleading and cost me a
while to figure out the actual cause.}}
A more suitable error message should probably indicate the name of the missing
feature that the model is trying to reference.
was:
When adding a model that references a non-existent feature a very ambiguous
error message is thrown, something like `Model type does not exist
org.apache.solr.ltr.model.{{LinearModel}}`
To reproduce, do not add any features and just add a model, for example by
doing this:
{{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
--data-binary '}}
{
{{ "class": "org.apache.solr.ltr.model.LinearModel",}}
{{ "name": "myModel",}}
{{ "features": [ \{"name": "whatever" }],}}
{{ "params": {"weights": {"whatever": 1.0
{{}' -H 'Content-type:application/json'}}
The resulting error message `Model type does not exist
{{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me a
while to figure out the actual cause.}}
A more suitable error message should probably indicate the name of the missing
feature that the model is trying to reference.
> When adding a model referencing a non-existent feature the error message is
> very ambiguous
> --
>
> Key: SOLR-12367
> URL: https://issues.apache.org/jira/browse/SOLR-12367
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 7.3.1
>Reporter: Georg Sorst
>Priority: Minor
>
> When adding a model that references a non-existent feature a very ambiguous
> error message is thrown, something like "Model type does not exist
> org.apache.solr.ltr.model.{{LinearModel}}".
>
> To reproduce, do not add any features and just add a model, for example by
> doing this:
>
> {{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
> --data-binary '}}
> {
> {{ "class": "org.apache.solr.ltr.model.LinearModel",}}
> {{ "name": "myModel",}}
> {{ "features": [ \{"name": "whatever" }],}}
> {{ "params": {"weights": {"whatever": 1.0
> {{}' -H 'Content-type:application/json'}}
>
> The resulting error message "Model type does not exist
> {{org.apache.solr.ltr.model.LinearModel" is extremely misleading and cost me
> a while to figure out the actual cause.}}
>
> A more suitable error message should probably indicate the name of the
> missing feature that the model is trying to reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12367) When adding a model referencing a non-existent feature the error message is very ambiguous
[
https://issues.apache.org/jira/browse/SOLR-12367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-12367:
---
Description:
When adding a model that references a non-existent feature a very ambiguous
error message is thrown, something like `Model type does not exist
org.apache.solr.ltr.model.{{LinearModel}}`
To reproduce, do not add any features and just add a model, for example by
doing this:
{{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
--data-binary '}}
{
{{ "class": "org.apache.solr.ltr.model.LinearModel",}}
{{ "name": "myModel",}}
{{ "features": [ \{"name": "whatever" }],}}
{{ "params": {"weights": {"whatever": 1.0
{{}' -H 'Content-type:application/json'}}
The resulting error message `Model type does not exist
{{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me a
while to figure out the actual cause.}}
A more suitable error message should probably indicate the name of the missing
feature that the model is trying to reference.
was:
When adding a model that references a non-existent feature a very ambiguous
error message is thrown, something like `Model type does not exist
org.apache.solr.ltr.model.{{LinearModel}}`
To reproduce, do not add any features and just add a model, for example by
doing this:
{{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
--data-binary '}}
{
{{ "class": "org.apache.solr.ltr.model.LinearModel",}}
{{ "name": "myModel",}}
{{ "features": [\{"name": "whatever" }],}}
{{ "params": {"weights": {"whatever": 1.0
{{}' -H 'Content-type:application/json'}}
The resulting error message `Model type does not exist
{{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me a
while to figure out the actual cause.}}
A more suitable error message should probably indicate the name of the missing
feature that the model is trying to reference.
> When adding a model referencing a non-existent feature the error message is
> very ambiguous
> --
>
> Key: SOLR-12367
> URL: https://issues.apache.org/jira/browse/SOLR-12367
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 7.3.1
>Reporter: Georg Sorst
>Priority: Minor
>
> When adding a model that references a non-existent feature a very ambiguous
> error message is thrown, something like `Model type does not exist
> org.apache.solr.ltr.model.{{LinearModel}}`
>
> To reproduce, do not add any features and just add a model, for example by
> doing this:
>
> {{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
> --data-binary '}}
> {
> {{ "class": "org.apache.solr.ltr.model.LinearModel",}}
> {{ "name": "myModel",}}
> {{ "features": [ \{"name": "whatever" }],}}
> {{ "params": {"weights": {"whatever": 1.0
> {{}' -H 'Content-type:application/json'}}
>
> The resulting error message `Model type does not exist
> {{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me
> a while to figure out the actual cause.}}
>
> A more suitable error message should probably indicate the name of the
> missing feature that the model is trying to reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12367) When adding a model referencing a non-existent feature the error message is very ambiguous
[
https://issues.apache.org/jira/browse/SOLR-12367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-12367:
---
Description:
When adding a model that references a non-existent feature a very ambiguous
error message is thrown, something like `Model type does not exist
org.apache.solr.ltr.model.{{LinearModel}}`
To reproduce, do not add any features and just add a model, for example by
doing this:
{{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
--data-binary '}}
{
{{ "class": "org.apache.solr.ltr.model.LinearModel",}}
{{ "name": "myModel",}}
{{ "features": [\{"name": "whatever" }],}}
{{ "params": {"weights": {"whatever": 1.0
{{}' -H 'Content-type:application/json'}}
The resulting error message `Model type does not exist
{{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me a
while to figure out the actual cause.}}
A more suitable error message should probably indicate the name of the missing
feature that the model is trying to reference.
was:
When adding a model that references a non-existent feature a very ambiguous
error message is thrown, something like `Model type does not exist
org.apache.solr.ltr.model.{{LinearModel}}`
To reproduce, do not add any features and just add a model, for example by
doing this:
{{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
--data-binary '}}
{{{}}
{{ "class": "org.apache.solr.ltr.model.LinearModel",}}
{{ "name": "myModel",}}
{{ "features": [\{"name": "whatever" }],}}
{{ "params": \{"weights": {"whatever": 1.0
{{}' -H 'Content-type:application/json'}}
The resulting error message `Model type does not exist
{{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me a
while to figure out the actual cause.}}
A more suitable error message should probably indicate the name of the missing
feature that the model is trying to reference.
> When adding a model referencing a non-existent feature the error message is
> very ambiguous
> --
>
> Key: SOLR-12367
> URL: https://issues.apache.org/jira/browse/SOLR-12367
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 7.3.1
>Reporter: Georg Sorst
>Priority: Minor
>
> When adding a model that references a non-existent feature a very ambiguous
> error message is thrown, something like `Model type does not exist
> org.apache.solr.ltr.model.{{LinearModel}}`
>
> To reproduce, do not add any features and just add a model, for example by
> doing this:
>
> {{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
> --data-binary '}}
> {
> {{ "class": "org.apache.solr.ltr.model.LinearModel",}}
> {{ "name": "myModel",}}
> {{ "features": [\{"name": "whatever" }],}}
> {{ "params": {"weights": {"whatever": 1.0
> {{}' -H 'Content-type:application/json'}}
>
> The resulting error message `Model type does not exist
> {{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me
> a while to figure out the actual cause.}}
>
> A more suitable error message should probably indicate the name of the
> missing feature that the model is trying to reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12367) When adding a model referencing a non-existent feature the error message is very ambiguous
[
https://issues.apache.org/jira/browse/SOLR-12367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-12367:
---
Summary: When adding a model referencing a non-existent feature the error
message is very ambiguous (was: In Solr LTR when adding a model referencing a
non-existent feature the error message is very ambiguous)
> When adding a model referencing a non-existent feature the error message is
> very ambiguous
> --
>
> Key: SOLR-12367
> URL: https://issues.apache.org/jira/browse/SOLR-12367
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 7.3.1
>Reporter: Georg Sorst
>Priority: Minor
>
> When adding a model that references a non-existent feature a very ambiguous
> error message is thrown, something like `Model type does not exist
> org.apache.solr.ltr.model.{{LinearModel}}`
>
> To reproduce, do not add any features and just add a model, for example by
> doing this:
>
> {{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
> --data-binary '}}
> {{{}}
> {{ "class": "org.apache.solr.ltr.model.LinearModel",}}
> {{ "name": "myModel",}}
> {{ "features": [\{"name": "whatever" }],}}
> {{ "params": \{"weights": {"whatever": 1.0
> {{}' -H 'Content-type:application/json'}}
>
> The resulting error message `Model type does not exist
> {{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me
> a while to figure out the actual cause.}}
>
> A more suitable error message should probably indicate the name of the
> missing feature that the model is trying to reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12367) In Solr LTR when adding a model referencing a non-existent feature the error message is very ambiguous
Georg Sorst created SOLR-12367:
--
Summary: In Solr LTR when adding a model referencing a
non-existent feature the error message is very ambiguous
Key: SOLR-12367
URL: https://issues.apache.org/jira/browse/SOLR-12367
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: contrib - LTR
Affects Versions: 7.3.1
Reporter: Georg Sorst
When adding a model that references a non-existent feature a very ambiguous
error message is thrown, something like `Model type does not exist
org.apache.solr.ltr.model.{{LinearModel}}`
To reproduce, do not add any features and just add a model, for example by
doing this:
{{curl -XPUT 'http://localhost:8983/solr/gettingstarted/schema/model-store'
--data-binary '}}
{{{}}
{{ "class": "org.apache.solr.ltr.model.LinearModel",}}
{{ "name": "myModel",}}
{{ "features": [\{"name": "whatever" }],}}
{{ "params": \{"weights": {"whatever": 1.0
{{}' -H 'Content-type:application/json'}}
The resulting error message `Model type does not exist
{{org.apache.solr.ltr.model.LinearModel` is extremely misleading and cost me a
while to figure out the actual cause.}}
A more suitable error message should probably indicate the name of the missing
feature that the model is trying to reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9968) Cannot use special characters in Suggester Context Query
[
https://issues.apache.org/jira/browse/SOLR-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15826929#comment-15826929
]
Georg Sorst edited comment on SOLR-9968 at 1/17/17 10:20 PM:
-
Make tokenizer for context filter queries configurable. Applies against Solr
6.3.
was (Author: gs):
Make tokenizer for context filter queries configurable
> Cannot use special characters in Suggester Context Query
>
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: SOLR-9968-configurable-tokenizer.patch,
> test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg.
> {noformat}suggest.cfq=context:c#x{noformat}
> * Escaping the character makes no difference, eg.
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is
> '{{c#x}}'
>
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}}
> can be used
> * Use the analyzer defined for the context field in the schema
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9968) Cannot use special characters in Suggester Context Query
[
https://issues.apache.org/jira/browse/SOLR-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15826939#comment-15826939
]
Georg Sorst commented on SOLR-9968:
---
I've implemented a fix ({{SOLR-9968-configurable-tokenizer.patch}}) for this
that fulfills my use case: Make the tokenizer to use for context filter queries
configurable. This makes it possible to use {{KeywordTokenizer}}, which handles
special characters just fine.
The config setting is {{contextFilterQueryTokenizer}}, it defaults to
{{StandardTokenizer}}.
The patch also contains a testcase.
The configuration uses the registered name (eg. {{keyword}}, {{standard}}) of
the Tokenizer instead of the class name (eg. {{solr.KeywordTokenizerFactory}},
{{solr.StandardTokenizerFactory}}. I would have preferred the latter way but
couldn't figure out how to do this properly.
I'll gladly change the behavior if it makes sense and someone can point me in
the right direction.
> Cannot use special characters in Suggester Context Query
>
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: SOLR-9968-configurable-tokenizer.patch,
> test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg.
> {noformat}suggest.cfq=context:c#x{noformat}
> * Escaping the character makes no difference, eg.
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is
> '{{c#x}}'
>
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}}
> can be used
> * Use the analyzer defined for the context field in the schema
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9968) Cannot use special characters in Suggester Context Query
[
https://issues.apache.org/jira/browse/SOLR-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9968:
--
Attachment: SOLR-9968-configurable-tokenizer.patch
Make tokenizer for context filter queries configurable
> Cannot use special characters in Suggester Context Query
>
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: SOLR-9968-configurable-tokenizer.patch,
> test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg.
> {noformat}suggest.cfq=context:c#x{noformat}
> * Escaping the character makes no difference, eg.
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is
> '{{c#x}}'
>
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}}
> can be used
> * Use the analyzer defined for the context field in the schema
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-9968) Cannot use special characters in Suggester Context Query
[
https://issues.apache.org/jira/browse/SOLR-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9968:
--
Comment: was deleted
(was: Test case)
> Cannot use special characters in Suggester Context Query
>
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg.
> {noformat}suggest.cfq=context:c#x{noformat}
> * Escaping the character makes no difference, eg.
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is
> '{{c#x}}'
>
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}}
> can be used
> * Use the analyzer defined for the context field in the schema
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9968) Cannot use special characters in Suggester Context Query
[
https://issues.apache.org/jira/browse/SOLR-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9968:
--
Attachment: (was: test_context_query_with_special_characters.patch)
> Cannot use special characters in Suggester Context Query
>
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg.
> {noformat}suggest.cfq=context:c#x{noformat}
> * Escaping the character makes no difference, eg.
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is
> '{{c#x}}'
>
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}}
> can be used
> * Use the analyzer defined for the context field in the schema
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9968) Cannot use special characters in Suggester Context Query
[
https://issues.apache.org/jira/browse/SOLR-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9968:
--
Attachment: test_context_query_with_special_characters.patch
Test case
> Cannot use special characters in Suggester Context Query
>
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg.
> {noformat}suggest.cfq=context:c#x{noformat}
> * Escaping the character makes no difference, eg.
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is
> '{{c#x}}'
>
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}}
> can be used
> * Use the analyzer defined for the context field in the schema
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9968) Cannot use special characters in Suggester Context Query
[
https://issues.apache.org/jira/browse/SOLR-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9968:
--
Description:
h4. Reproduce
1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
2. Add a document containing special characters in that field, eg. '{{c#x}}'
3. Use a context query with the Suggester, eg.
{noformat}suggest.cfq=context:c#x{noformat}
* Escaping the character makes no difference, eg.
{noformat}suggest.cfq=context:c\#x{noformat}
h4. What happens
The suggestions are not properly filtered
h4. What should happen
The suggestions should be limited to documents where the field {{context}} is
'{{c#x}}'
What happens is this:
1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
{{StandardTokenizer}}
2. The context query is parsed like this:
{code:title=SolrSuggester.parseContextFilterQuery}
query = new
StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
CONTEXTS_FIELD_NAME);
{code}
3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
the context query into '{{context:c context:x}}'
4. This is used for filtering the suggestions
5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to
reproduce this behavior.
So, the question is, how to get the parser and tokenizer to use these special
characters verbatim? Two ways I can think of:
* Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} can
be used
* Use the analyzer defined for the context field in the schema
was:
h4. Reproduce
1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
2. Add a document containing special characters in that field, eg. '{{c#x}}'
3. Use a context query with the Suggester, eg.
{noformat}suggest.cfq=context:c#x{noformat}
* Escaping the character makes no difference, eg.
{noformat}suggest.cfq=context:c\#x{noformat}
h4. What happens
The suggestions are not properly filtered
h4. What should happen
The suggestions should be limited to documents where the field {{context}} is
'{{c#x}}'
What happens is this:
1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
{{StandardTokenizer}}
2. The context query is parsed like this:
{code:title=SolrSuggester.parseContextFilterQuery}
query = new
StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
CONTEXTS_FIELD_NAME);
{code}
3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
the context query into '{{context:c context:x}}'
4. This is used for filtering the suggestions
5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
So, the question is, how to get the parser and tokenizer to use these special
characters verbatim? Two ways I can think of:
* Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} can
be used
* Use the analyzer defined for the context field in the schema
> Cannot use special characters in Suggester Context Query
>
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg.
> {noformat}suggest.cfq=context:c#x{noformat}
> * Escaping the character makes no difference, eg.
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is
> '{{c#x}}'
>
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special
> characters verbatim? Two ways I can think of:
> * Make
[jira] [Updated] (SOLR-9968) Cannot use special characters in Suggester Context Query
[
https://issues.apache.org/jira/browse/SOLR-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9968:
--
Attachment: test_context_query_with_special_characters.patch
Test case
> Cannot use special characters in Suggester Context Query
>
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg.
> {noformat}suggest.cfq=context:c#x{noformat}
> * Escaping the character makes no difference, eg.
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is
> '{{c#x}}'
>
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> So, the question is, how to get the parser and tokenizer to use these special
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}}
> can be used
> * Use the analyzer defined for the context field in the schema
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9968) Cannot use special characters in Suggester Context Query
Georg Sorst created SOLR-9968:
-
Summary: Cannot use special characters in Suggester Context Query
Key: SOLR-9968
URL: https://issues.apache.org/jira/browse/SOLR-9968
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Suggester
Affects Versions: 6.3, 6.0
Reporter: Georg Sorst
h4. Reproduce
1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
2. Add a document containing special characters in that field, eg. '{{c#x}}'
3. Use a context query with the Suggester, eg.
{noformat}suggest.cfq=context:c#x{noformat}
* Escaping the character makes no difference, eg.
{noformat}suggest.cfq=context:c\#x{noformat}
h4. What happens
The suggestions are not properly filtered
h4. What should happen
The suggestions should be limited to documents where the field {{context}} is
'{{c#x}}'
What happens is this:
1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use
{{StandardTokenizer}}
2. The context query is parsed like this:
{code:title=SolrSuggester.parseContextFilterQuery}
query = new
StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter,
CONTEXTS_FIELD_NAME);
{code}
3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn
the context query into '{{context:c context:x}}'
4. This is used for filtering the suggestions
5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
So, the question is, how to get the parser and tokenizer to use these special
characters verbatim? Two ways I can think of:
* Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} can
be used
* Use the analyzer defined for the context field in the schema
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito
[
https://issues.apache.org/jira/browse/SOLR-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9081:
--
Affects Version/s: 5.5
5.5.1
> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
> Issue Type: Bug
> Components: Tests
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Georg Sorst
>Priority: Blocker
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are
> currently defined as {{private static void}}. This causes problems with
> Mockito, which requires all test framework methods (including
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}.
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
> /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be
> public}}
> The very trivial fix is to change both methods to {{public static void}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito
[
https://issues.apache.org/jira/browse/SOLR-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9081:
--
Affects Version/s: 6.0.1
> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
> Issue Type: Bug
> Components: Tests
>Affects Versions: 6.0, 6.0.1
>Reporter: Georg Sorst
>Priority: Blocker
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are
> currently defined as {{private static void}}. This causes problems with
> Mockito, which requires all test framework methods (including
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}.
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
> /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be
> public}}
> The very trivial fix is to change both methods to {{public static void}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito
[
https://issues.apache.org/jira/browse/SOLR-9081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Sorst updated SOLR-9081:
--
Description:
{{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are
currently defined as {{private static void}}. This causes problems with
Mockito, which requires all test framework methods (including {{@BeforeClass}}
/ {{@AfterClass}}) to be {{public}}.
The following test case will show this:
{code:title=MockitoTest.java|borderStyle=solid}
package com.example;
import org.apache.solr.SolrTestCaseJ4;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.runners.MockitoJUnitRunner;
@RunWith(MockitoJUnitRunner.class)
public class MockitoTest extends SolrTestCaseJ4 {
@Test
public void testSomething() {
/* Nothing to do, the test runner will fail right away */
}
}
{code}
It will fail with {{java.lang.Exception: Method beforeClass() should be public}}
The very trivial fix is to change both methods to {{public static void}}
was:
{{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are
currently defined as {{private static void}}. This causes problems with
Mockito, which requires all test framework methods (including {{@BeforeClass}}
/ {{@AfterClass}}) to be {{public}}.
The following test case will show this:
{code:title=MockitoTest.java|borderStyle=solid}
package com.example;
import org.apache.solr.SolrTestCaseJ4;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.runners.MockitoJUnitRunner;
@RunWith(MockitoJUnitRunner.class)
public class MockitoTest extends SolrTestCaseJ4 {
@Test
public void testSomething() {
/* Nothing to do, the test runner will fail right away */
}
}
{code}
It will fail with {{java.lang.Exception: Method beforeClass() should be public}}
> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
> Issue Type: Bug
> Components: Tests
>Affects Versions: 6.0
>Reporter: Georg Sorst
>Priority: Blocker
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are
> currently defined as {{private static void}}. This causes problems with
> Mockito, which requires all test framework methods (including
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}.
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
> /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be
> public}}
> The very trivial fix is to change both methods to {{public static void}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito
Georg Sorst created SOLR-9081:
-
Summary: Make SolrTestCaseJ4.beforeClass() / .afterClass() public
so it works with Mockito
Key: SOLR-9081
URL: https://issues.apache.org/jira/browse/SOLR-9081
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 6.0
Reporter: Georg Sorst
Priority: Blocker
{{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are
currently defined as {{private static void}}. This causes problems with
Mockito, which requires all test framework methods (including {{@BeforeClass}}
/ {{@AfterClass}}) to be {{public}}.
The following test case will show this:
{code:title=MockitoTest.java|borderStyle=solid}
package com.example;
import org.apache.solr.SolrTestCaseJ4;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.runners.MockitoJUnitRunner;
@RunWith(MockitoJUnitRunner.class)
public class MockitoTest extends SolrTestCaseJ4 {
@Test
public void testSomething() {
/* Nothing to do, the test runner will fail right away */
}
}
{code}
It will fail with {{java.lang.Exception: Method beforeClass() should be public}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2834) AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter
[ https://issues.apache.org/jira/browse/SOLR-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981982#comment-13981982 ] Georg Sorst commented on SOLR-2834: --- [~elyograg] Any pointers on how I could fix this (see above)? AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter - Key: SOLR-2834 URL: https://issues.apache.org/jira/browse/SOLR-2834 Project: Solr Issue Type: Bug Components: clients - java, Schema and Analysis Affects Versions: 3.4, 3.6, 4.2 Reporter: Shane Assignee: Shalin Shekhar Mangar Priority: Blocker Labels: patch Attachments: AnalysisResponseBase.patch Original Estimate: 5m Remaining Estimate: 5m When using FieldAnalysisRequest.java to analysis a field, a ClassCastExcpetion is thrown if the schema defines the filter org.apache.solr.analysis.HTMLStripCharFilter. The exception is: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.List at org.apache.solr.client.solrj.response.AnalysisResponseBase.buildPhases(AnalysisResponseBase.java:69) at org.apache.solr.client.solrj.response.FieldAnalysisResponse.setResponse(FieldAnalysisResponse.java:66) at org.apache.solr.client.solrj.request.FieldAnalysisRequest.process(FieldAnalysisRequest.java:107) My schema definition is: fieldType name=text class=solr.TextField positionIncrementGap=100 analyzer charFilter class=solr.HTMLStripCharFilterFactory / tokenizer class=solr.StandardTokenizerFactory / filter class=solr.StandardFilterFactory / filter class=solr.TrimFilterFactory / filter class=solr.LowerCaseFilterFactory / /analyzer /fieldType The response is part is: lst name=query str name=org.apache.solr.analysis.HTMLStripCharFiltertesting analysis/str arr name=org.apache.lucene.analysis.standard.StandardTokenizer lst... A simplistic fix would be to test if the Entry value is an instance of List. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-2834) AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter
[
https://issues.apache.org/jira/browse/SOLR-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967819#comment-13967819
]
Georg Sorst edited comment on SOLR-2834 at 4/13/14 1:35 PM:
I can verfiy that this is still open for Solr 4.4.
I would really like to fix this issue, but need some advice on what / where to
fix exactly. I see two options:
# Fix the output of the field-analysis request so that it uses {{arr ...}} for
CharFilters just like it does for Tokenizers and TokenFilters
** This will probably confuse Solr Admin and who knows what else
# Fix the {{FieldAnalysisResponse}} / {{AnalysisResponseBase}} so that it can
deal with the current response format ({{str ..}} for CharFilters)
** The {{AnalysisResponseBase}} assumes in many places that the output is
{{arr-lst-str}} due to the Generics of the NamedLists; it would be hard to
make this change decently type-safe
I'm a bit lost here. If someone could give me a few pointers which option is
better and which tests to adapt I'll glady try to take care of it.
was (Author: gs):
I would really like to fix this issue, but need some advice on what / where to
fix exactly. I see two options:
# Fix the output of the field-analysis request so that it uses {{arr ...}} for
CharFilters just like it does for Tokenizers and TokenFilters
** This will probably confuse Solr Admin and who knows what else
# Fix the {{FieldAnalysisResponse}} / {{AnalysisResponseBase}} so that it can
deal with the current response format ({{str ..}} for CharFilters)
** The {{AnalysisResponseBase}} assumes in many places that the output is
{{arr-lst-str}} due to the Generics of the NamedLists; it would be hard to
make this change decently type-safe
I'm a bit lost here. If someone could give me a few pointers which option is
better and which tests to adapt I'll glady try to take care of it.
AnalysisResponseBase.java doesn't handle
org.apache.solr.analysis.HTMLStripCharFilter
-
Key: SOLR-2834
URL: https://issues.apache.org/jira/browse/SOLR-2834
Project: Solr
Issue Type: Bug
Components: clients - java, Schema and Analysis
Affects Versions: 3.4, 3.6, 4.2
Reporter: Shane
Assignee: Shalin Shekhar Mangar
Priority: Blocker
Labels: patch
Attachments: AnalysisResponseBase.patch
Original Estimate: 5m
Remaining Estimate: 5m
When using FieldAnalysisRequest.java to analysis a field, a
ClassCastExcpetion is thrown if the schema defines the filter
org.apache.solr.analysis.HTMLStripCharFilter. The exception is:
java.lang.ClassCastException: java.lang.String cannot be cast to
java.util.List
at
org.apache.solr.client.solrj.response.AnalysisResponseBase.buildPhases(AnalysisResponseBase.java:69)
at
org.apache.solr.client.solrj.response.FieldAnalysisResponse.setResponse(FieldAnalysisResponse.java:66)
at
org.apache.solr.client.solrj.request.FieldAnalysisRequest.process(FieldAnalysisRequest.java:107)
My schema definition is:
fieldType name=text class=solr.TextField positionIncrementGap=100
analyzer
charFilter class=solr.HTMLStripCharFilterFactory /
tokenizer class=solr.StandardTokenizerFactory /
filter class=solr.StandardFilterFactory /
filter class=solr.TrimFilterFactory /
filter class=solr.LowerCaseFilterFactory /
/analyzer
/fieldType
The response is part is:
lst name=query
str name=org.apache.solr.analysis.HTMLStripCharFiltertesting
analysis/str
arr name=org.apache.lucene.analysis.standard.StandardTokenizer
lst...
A simplistic fix would be to test if the Entry value is an instance of List.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2834) AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter
[
https://issues.apache.org/jira/browse/SOLR-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967819#comment-13967819
]
Georg Sorst commented on SOLR-2834:
---
I would really like to fix this issue, but need some advice on what / where to
fix exactly. I see two options:
# Fix the output of the field-analysis request so that it uses {{arr ...}} for
CharFilters just like it does for Tokenizers and TokenFilters
** This will probably confuse Solr Admin and who knows what else
# Fix the {{FieldAnalysisResponse}} / {{AnalysisResponseBase}} so that it can
deal with the current response format ({{str ..}} for CharFilters)
** The {{AnalysisResponseBase}} assumes in many places that the output is
{{arr-lst-str}} due to the Generics of the NamedLists; it would be hard to
make this change decently type-safe
I'm a bit lost here. If someone could give me a few pointers which option is
better and which tests to adapt I'll glady try to take care of it.
AnalysisResponseBase.java doesn't handle
org.apache.solr.analysis.HTMLStripCharFilter
-
Key: SOLR-2834
URL: https://issues.apache.org/jira/browse/SOLR-2834
Project: Solr
Issue Type: Bug
Components: clients - java, Schema and Analysis
Affects Versions: 3.4, 3.6, 4.2
Reporter: Shane
Assignee: Shalin Shekhar Mangar
Priority: Blocker
Labels: patch
Attachments: AnalysisResponseBase.patch
Original Estimate: 5m
Remaining Estimate: 5m
When using FieldAnalysisRequest.java to analysis a field, a
ClassCastExcpetion is thrown if the schema defines the filter
org.apache.solr.analysis.HTMLStripCharFilter. The exception is:
java.lang.ClassCastException: java.lang.String cannot be cast to
java.util.List
at
org.apache.solr.client.solrj.response.AnalysisResponseBase.buildPhases(AnalysisResponseBase.java:69)
at
org.apache.solr.client.solrj.response.FieldAnalysisResponse.setResponse(FieldAnalysisResponse.java:66)
at
org.apache.solr.client.solrj.request.FieldAnalysisRequest.process(FieldAnalysisRequest.java:107)
My schema definition is:
fieldType name=text class=solr.TextField positionIncrementGap=100
analyzer
charFilter class=solr.HTMLStripCharFilterFactory /
tokenizer class=solr.StandardTokenizerFactory /
filter class=solr.StandardFilterFactory /
filter class=solr.TrimFilterFactory /
filter class=solr.LowerCaseFilterFactory /
/analyzer
/fieldType
The response is part is:
lst name=query
str name=org.apache.solr.analysis.HTMLStripCharFiltertesting
analysis/str
arr name=org.apache.lucene.analysis.standard.StandardTokenizer
lst...
A simplistic fix would be to test if the Entry value is an instance of List.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2834) AnalysisResponseBase.java doesn't handle org.apache.solr.analysis.HTMLStripCharFilter
[
https://issues.apache.org/jira/browse/SOLR-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967896#comment-13967896
]
Georg Sorst commented on SOLR-2834:
---
[~elyograg] The issue still exists in 4.7.1. Unfortunately I could not get
4.7.2 to run ({{svn checkout}} would insist on a redirect to the same URL) but
from looking at the code it exists there as well.
AnalysisResponseBase.java doesn't handle
org.apache.solr.analysis.HTMLStripCharFilter
-
Key: SOLR-2834
URL: https://issues.apache.org/jira/browse/SOLR-2834
Project: Solr
Issue Type: Bug
Components: clients - java, Schema and Analysis
Affects Versions: 3.4, 3.6, 4.2
Reporter: Shane
Assignee: Shalin Shekhar Mangar
Priority: Blocker
Labels: patch
Attachments: AnalysisResponseBase.patch
Original Estimate: 5m
Remaining Estimate: 5m
When using FieldAnalysisRequest.java to analysis a field, a
ClassCastExcpetion is thrown if the schema defines the filter
org.apache.solr.analysis.HTMLStripCharFilter. The exception is:
java.lang.ClassCastException: java.lang.String cannot be cast to
java.util.List
at
org.apache.solr.client.solrj.response.AnalysisResponseBase.buildPhases(AnalysisResponseBase.java:69)
at
org.apache.solr.client.solrj.response.FieldAnalysisResponse.setResponse(FieldAnalysisResponse.java:66)
at
org.apache.solr.client.solrj.request.FieldAnalysisRequest.process(FieldAnalysisRequest.java:107)
My schema definition is:
fieldType name=text class=solr.TextField positionIncrementGap=100
analyzer
charFilter class=solr.HTMLStripCharFilterFactory /
tokenizer class=solr.StandardTokenizerFactory /
filter class=solr.StandardFilterFactory /
filter class=solr.TrimFilterFactory /
filter class=solr.LowerCaseFilterFactory /
/analyzer
/fieldType
The response is part is:
lst name=query
str name=org.apache.solr.analysis.HTMLStripCharFiltertesting
analysis/str
arr name=org.apache.lucene.analysis.standard.StandardTokenizer
lst...
A simplistic fix would be to test if the Entry value is an instance of List.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
