[jira] [Commented] (SOLR-7691) SolrEntityProcessor as SubEntity doesn't work with delta-import
[
https://issues.apache.org/jira/browse/SOLR-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432676#comment-15432676
]
Zaccheo Bagnati commented on SOLR-7691:
---
I'm experiencing the same error. It happens for sure also in 5.5.0 and 6.1.0.
> SolrEntityProcessor as SubEntity doesn't work with delta-import
> ---
>
> Key: SOLR-7691
> URL: https://issues.apache.org/jira/browse/SOLR-7691
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1
>Reporter: Sebastian Krebs
>
> I've used the {{SolrEntityProcessor}} as sub-entity in the dataimporter like
> this
> {code:lang=xml}
>
>
> name="outer"
> dataSource="my_datasource"
> pk="id"
> query="..."
> deltaQuery="..."
> deltaImportQuery="..."
> >
> name="solr"
> processor="SolrEntityProcessor"
> url="http://127.0.0.1:8983/solr/${solr.core.name}";
> query="Xid:${outer.Xid}"
> rows="1"
> fl="Id,FieldA,FieldB"
> wt="javabin"
> />
>
>
>
> {code}
> Recently I decided to upgrade to 5.x, but the delta-import stopped working.
> At all it looks like the http-connection used by the {{SolrEntityProcessor}}
> is closed right _after_ the request/response, because the first document is
> indexed properly and for the second connection the dataimport fetches the
> record from the database, but after that exists
> This is the stacktrace taken from the log
> {code:lang=none}
> java.lang.RuntimeException: java.lang.RuntimeException:
> org.apache.solr.handler.dataimport.DataImportHandlerException:
> java.lang.IllegalStateException: Connection pool shut down
> at
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:270)
> at
> org.apache.solr.handler.dataimport.DataImporter.doDeltaImport(DataImporter.java:444)
> at
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:482)
> at
> org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:461)
> Caused by: java.lang.RuntimeException:
> org.apache.solr.handler.dataimport.DataImportHandlerException:
> java.lang.IllegalStateException: Connection pool shut down
> at
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:416)
> at
> org.apache.solr.handler.dataimport.DocBuilder.doDelta(DocBuilder.java:363)
> at
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:224)
> ... 3 more
> Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException:
> java.lang.IllegalStateException: Connection pool shut down
> at
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:62)
> at
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:246)
> at
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:475)
> at
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:514)
> at
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414)
> ... 5 more
> Caused by: java.lang.IllegalStateException: Connection pool shut down
> at org.apache.http.util.Asserts.check(Asserts.java:34)
> at org.apache.http.pool.AbstractConnPool.lease(AbstractConnPool.java:184)
> at org.apache.http.pool.AbstractConnPool.lease(AbstractConnPool.java:217)
> at
> org.apache.http.impl.conn.PoolingClientConnectionManager.requestConnection(PoolingClientConnectionManager.java:184)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
> at
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:466)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
> at
> org.apache.solr.han
[jira] [Commented] (SOLR-8537) phrase highlighter doesn't work when searching for phrase containing some stopwords
[
https://issues.apache.org/jira/browse/SOLR-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118861#comment-15118861
]
Zaccheo Bagnati commented on SOLR-8537:
---
Thank you David for your answer. So the best option seems to be switching to
5.*: I'll investigate impacts for the migration
> phrase highlighter doesn't work when searching for phrase containing some
> stopwords
> ---
>
> Key: SOLR-8537
> URL: https://issues.apache.org/jira/browse/SOLR-8537
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Affects Versions: 4.10.4
>Reporter: Zaccheo Bagnati
>
> When executing a phrase search containing 3 or more stopwords highlight is
> empty.
> Example:
> {code:xml|title=solrconfig.xml}
>
>
> LUCENE_4_10
>class="org.apache.solr.handler.admin.AdminHandlers" />
>
>
>class="solr.FieldAnalysisRequestHandler" startup="lazy"/>
>
> {code}
> {code:xml|title=schema.xml}
>
>
>
> positionIncrementGap="0"/>
> omitNorms="true"/>
>
>
>
> words="stopwords.txt" format="snowball" enablePositionIncrements="true"/>
>
>
>
>
>
> multiValued="false" />
> multiValued="false" />
>
> id
> document_text
>
> {code}
> {code:title=stopwords.txt}
> c
> e
> g
> {code}
> Load this document:
> {code:xml}
>
>
> 1
> a c b d a b c d e f g h i a f g b e
>
>
> {code}
> Execute query:
> http://myhost:8983/solr/test_hl/select?q=%22a+b+c+d+e+f+g+h%22&wt=json&indent=true&hl=true&hl.fl=document_text&hl.simple.pre=%3Cem%3E&hl.simple.post=%3C%2Fem%3E
> This is the result:
> {code:javascript}
> {
> "responseHeader":{
> "status":0,
> "QTime":2},
> "response":{"numFound":1,"start":0,"docs":[
> {
> "id":"1",
> "document_text":"a c b d a b c d e f g h i a f g b e"}]
> },
> "highlighting":{
> "1":{}}}
> {code}
> Highlighting for document 1 is empty!
> Searching for "a b c d e f g" works correctly
> This problem does not affect solr 5.4
--
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-8537) phrase highlighter doesn't work when searching for phrase containing some stopwords
[
https://issues.apache.org/jira/browse/SOLR-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zaccheo Bagnati updated SOLR-8537:
--
Priority: Major (was: Minor)
> phrase highlighter doesn't work when searching for phrase containing some
> stopwords
> ---
>
> Key: SOLR-8537
> URL: https://issues.apache.org/jira/browse/SOLR-8537
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Affects Versions: 4.10.4
>Reporter: Zaccheo Bagnati
>
> When executing a phrase search containing 3 or more stopwords highlight is
> empty.
> Example:
> {code:xml|title=solrconfig.xml}
>
>
> LUCENE_4_10
>class="org.apache.solr.handler.admin.AdminHandlers" />
>
>
>class="solr.FieldAnalysisRequestHandler" startup="lazy"/>
>
> {code}
> {code:xml|title=schema.xml}
>
>
>
> positionIncrementGap="0"/>
> omitNorms="true"/>
>
>
>
> words="stopwords.txt" format="snowball" enablePositionIncrements="true"/>
>
>
>
>
>
> multiValued="false" />
> multiValued="false" />
>
> id
> document_text
>
> {code}
> {code:title=stopwords.txt}
> c
> e
> g
> {code}
> Load this document:
> {code:xml}
>
>
> 1
> a c b d a b c d e f g h i a f g b e
>
>
> {code}
> Execute query:
> http://myhost:8983/solr/test_hl/select?q=%22a+b+c+d+e+f+g+h%22&wt=json&indent=true&hl=true&hl.fl=document_text&hl.simple.pre=%3Cem%3E&hl.simple.post=%3C%2Fem%3E
> This is the result:
> {code:javascript}
> {
> "responseHeader":{
> "status":0,
> "QTime":2},
> "response":{"numFound":1,"start":0,"docs":[
> {
> "id":"1",
> "document_text":"a c b d a b c d e f g h i a f g b e"}]
> },
> "highlighting":{
> "1":{}}}
> {code}
> Highlighting for document 1 is empty!
> Searching for "a b c d e f g" works correctly
> This problem does not affect solr 5.4
--
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-8537) phrase highlighter doesn't work when searching for phrase containing some stopwords
Zaccheo Bagnati created SOLR-8537:
-
Summary: phrase highlighter doesn't work when searching for phrase
containing some stopwords
Key: SOLR-8537
URL: https://issues.apache.org/jira/browse/SOLR-8537
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 4.10.4
Reporter: Zaccheo Bagnati
Priority: Minor
When executing a phrase search containing 3 or more stopwords highlight is
empty.
Example:
{code:xml|title=solrconfig.xml}
LUCENE_4_10
{code}
{code:xml|title=schema.xml}
id
document_text
{code}
{code:title=stopwords.txt}
c
e
g
{code}
Load this document:
{code:xml}
1
a c b d a b c d e f g h i a f g b e
{code}
Execute query:
http://myhost:8983/solr/test_hl/select?q=%22a+b+c+d+e+f+g+h%22&wt=json&indent=true&hl=true&hl.fl=document_text&hl.simple.pre=%3Cem%3E&hl.simple.post=%3C%2Fem%3E
This is the result:
{code:javascript}
{
"responseHeader":{
"status":0,
"QTime":2},
"response":{"numFound":1,"start":0,"docs":[
{
"id":"1",
"document_text":"a c b d a b c d e f g h i a f g b e"}]
},
"highlighting":{
"1":{}}}
{code}
Highlighting for document 1 is empty!
Searching for "a b c d e f g" works correctly
This problem does not affect solr 5.4
--
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-6187) facet.mincount ignored in range faceting using distributed search
[
https://issues.apache.org/jira/browse/SOLR-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129728#comment-14129728
]
Zaccheo Bagnati commented on SOLR-6187:
---
Sorry for not giving feedback but I',m not familiar with SOLR source code.
Can you please correct my name in CHANGES.txt: it's misspelled. Thank you.
> facet.mincount ignored in range faceting using distributed search
> -
>
> Key: SOLR-6187
> URL: https://issues.apache.org/jira/browse/SOLR-6187
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.8, 4.8.1
>Reporter: Zaccheo Bagnati
>Assignee: Erick Erickson
> Fix For: 4.11, 5.0
>
> Attachments: SOLR-6187.patch, SOLR-6187.patch, SOLR-6187.patch,
> SOLR-6187.patch, SOLR-6187.patch, SOLR-6187.patch
>
>
> While I was trying to do a range faceting with gap +1YEAR using shards, I
> noticed that facet.mincount parameter seems to be ignored.
> Issue can be reproduced in this way:
> Create 2 cores "testshard1" and "testshard2" with:
> solrconfig.xml
>
>
> LUCENE_41
>
>class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}"/>
>
>
>
>explicit
>10
>id
>
>
>
>class="org.apache.solr.handler.admin.AdminHandlers" />
>
>
> solrpingquery
>
>
> all
>
>
>
> schema.xml
>
> xmlns:xi="http://www.w3.org/2001/XInclude";>
>positionIncrementGap="0"/>
>positionIncrementGap="0"/>
>positionIncrementGap="0"/>
>
>multiValued="false" />
>multiValued="false" />
> id
> id
>
> Insert in testshard1:
>
>
> 1
> 2014-06-20T12:51:00Z
>
>
> Insert into testshard2:
>
>
> 2
> 2013-06-20T12:51:00Z
>
>
> Now if I execute:
> curl
> "http://localhost:8983/solr/testshard1/select?q=id:1&facet=true&facet.mincount=1&facet.range=date&f.date.facet.range.start=1900-01-01T00:00:00Z&f.date.facet.range.end=NOW&f.date.facet.range.gap=%2B1YEAR&shards=localhost%3A8983%2Fsolr%2Ftestshard1%2Clocalhost%3A8983%2Fsolr%2Ftestshard2&shards.info=true&wt=json";
> I obtain:
> {"responseHeader":{"status":0,"QTime":88,"params":{"f.date.facet.range.gap":"+1YEAR","f.date.facet.range.start":"1900-01-01T00:00:00Z","facet":"true","shards":"localhost:8983/solr/testshard1,localhost:8983/solr/testshard2","facet.mincount":"1","q":"id:1","shards.info":"true","facet.range":"date","wt":"json","f.date.facet.range.end":"NOW"}},"shards.info":{"localhost:8983/solr/testshard2":{"numFound":0,"maxScore":0.0,"shardAddress":"http://localhost:8983/solr/testshard2","time":76},"localhost:8983/solr/testshard1":{"numFound":1,"maxScore":0.30685282,"shardAddress":"http://localhost:8983/solr/testshard1","time":79}},"response":{"numFound":1,"start":0,"maxScore":0.30685282,"docs":[{"id":1,"date":"2014-06-20T12:51:00Z"}]},"facet_counts":{"facet_queries":{},"facet_fields":{},"facet_dates":{},"facet_ranges":{"date":{"counts":["1900-01-01T00:00:00Z",0,"1901-01-01T00:00:00Z",0,"1902-01-01T00:00:00Z",0,"1903-01-01T00:00:00Z",0,"1904-01-01T00:00:00Z",0,"1905-01-01T00:00:00Z",0,"1906-01-01T00:00:00Z",0,"1907-01-01T00:00:00Z",0,"1908-01-01T00:00:00Z",0,"1909-01-01T00:00:00Z",0,"1910-01-01T00:00:00Z",0,"1911-01-01T00:00:00Z",0,"1912-01-01T00:00:00Z",0,"1913-01-01T00:00:00Z",0,"1914-01-01T00:00:00Z",0,"1915-01-01T00:00:00Z",0,"1916-01-01T00:00:00Z",0,"1917-01-01T00:00:00Z",0,"1918-01-01T00:00:00Z",0,"1919-01-01T00:00:00Z",0,"1920-01-01T00:00:00Z",0,"1921-01-01T00:00:00Z",0,"1922-01-01T00:00:00Z",0,"1923-01-01T00:00:00Z",0,"1924-01-01T00:00:00Z",0,"1925-01-01T00:00:00Z",0,"1926-01-01T00:00:00Z",0,"1927-01-01T00:00:00Z",0,"1928-01-01T00:00:00Z",0,"1929-01-01T00:00:00Z",0,"1930-01-01T00:00:00Z",0,"1931-01-01T00:00:00Z",0,"1932-01-01T00:00:00Z",0,"1933-01-01T00:00:00Z",0,"1934-01-01T00:00:00Z",0,"1935-01-01T00:00:00Z",0,"1936-01-01T00:00:00Z",0,"1937-01-01T00:00:00Z",0,"1938-01-01T00:00:00Z",0,"1939-01-01T00:00:00Z",0,"1940-01-01T00:00:00Z",0,"1941-01-01T00:00:00Z",0,"1942-01-01T00:00:00Z",0,"1943-01-01T00:00:00Z",0,"1944-01-01T00:00:00Z",0,"1945-01-01T00:00:00Z",0,"1946-01-01T00:00:00Z",0,"1947-01-01T00:00:00Z",0,"1948-01-01T00:00:00Z",0,"1949-01-01T00:00:00Z",0,"1950-01-01T00:00:00Z",0,"1951-01-01T00:00:00Z",0,"1952-01-01T00:00:00Z",0,"1953-01-01T00:00:00Z",0,"1954-01-01T00:00:00Z",0,"1955-01-01T00:00:00Z",0,"1956-01-01T00:00:00Z",0,"1957-01-01T00:00:00Z",0,"1958-01-01T00:00:00Z",0,"1959-01-01T00:00:00Z",0,"1960-01-01T00:00:00Z",0,"1961-01-01T00:00:00Z",0,"1962-01-01T00:00:00Z",0,"1963-01-01T00:00:00Z",0,"1964-01-01T00:00:00Z",0,"1965-01-01T00:00:00Z",0,"1966-01-01T00:00:00Z",0,"1967-01-01T00:00:00Z",0,"1968-01-01T00:00:00Z",0,"1969-01-01T00:00:00Z",0,"1970-01-01T00:00:00Z",0,"1971-01-01T00:00:00Z",0,"1972-01-01T00:00:00Z",0,"1973-01-01T00:00:00Z",0,"1974-01-01T00:0
[jira] [Created] (SOLR-6187) facet.mincount ignored in range date faceting using distributed search
Zaccheo Bagnati created SOLR-6187:
-
Summary: facet.mincount ignored in range date faceting using
distributed search
Key: SOLR-6187
URL: https://issues.apache.org/jira/browse/SOLR-6187
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.8.1, 4.8
Reporter: Zaccheo Bagnati
While I was trying to do a range faceting with gap +1YEAR using shards, I
noticed that facet.mincount parameter seems to be ignored.
Issue can be reproduced in this way:
Create 2 cores "testshard1" and "testshard2" with:
solrconfig.xml
LUCENE_41
explicit
10
id
solrpingquery
all
schema.xml
http://www.w3.org/2001/XInclude";>
id
id
Insert in testshard1:
1
2014-06-20T12:51:00Z
Insert into testshard2:
2
2013-06-20T12:51:00Z
Now if I execute:
curl
"http://localhost:8983/solr/testshard1/select?q=id:1&facet=true&facet.mincount=1&facet.range=date&f.date.facet.range.start=1900-01-01T00:00:00Z&f.date.facet.range.end=NOW&f.date.facet.range.gap=%2B1YEAR&shards=localhost%3A8983%2Fsolr%2Ftestshard1%2Clocalhost%3A8983%2Fsolr%2Ftestshard2&shards.info=true&wt=json";
I obtain:
{"responseHeader":{"status":0,"QTime":88,"params":{"f.date.facet.range.gap":"+1YEAR","f.date.facet.range.start":"1900-01-01T00:00:00Z","facet":"true","shards":"localhost:8983/solr/testshard1,localhost:8983/solr/testshard2","facet.mincount":"1","q":"id:1","shards.info":"true","facet.range":"date","wt":"json","f.date.facet.range.end":"NOW"}},"shards.info":{"localhost:8983/solr/testshard2":{"numFound":0,"maxScore":0.0,"shardAddress":"http://localhost:8983/solr/testshard2","time":76},"localhost:8983/solr/testshard1":{"numFound":1,"maxScore":0.30685282,"shardAddress":"http://localhost:8983/solr/testshard1","time":79}},"response":{"numFound":1,"start":0,"maxScore":0.30685282,"docs":[{"id":1,"date":"2014-06-20T12:51:00Z"}]},"facet_counts":{"facet_queries":{},"facet_fields":{},"facet_dates":{},"facet_ranges":{"date":{"counts":["1900-01-01T00:00:00Z",0,"1901-01-01T00:00:00Z",0,"1902-01-01T00:00:00Z",0,"1903-01-01T00:00:00Z",0,"1904-01-01T00:00:00Z",0,"1905-01-01T00:00:00Z",0,"1906-01-01T00:00:00Z",0,"1907-01-01T00:00:00Z",0,"1908-01-01T00:00:00Z",0,"1909-01-01T00:00:00Z",0,"1910-01-01T00:00:00Z",0,"1911-01-01T00:00:00Z",0,"1912-01-01T00:00:00Z",0,"1913-01-01T00:00:00Z",0,"1914-01-01T00:00:00Z",0,"1915-01-01T00:00:00Z",0,"1916-01-01T00:00:00Z",0,"1917-01-01T00:00:00Z",0,"1918-01-01T00:00:00Z",0,"1919-01-01T00:00:00Z",0,"1920-01-01T00:00:00Z",0,"1921-01-01T00:00:00Z",0,"1922-01-01T00:00:00Z",0,"1923-01-01T00:00:00Z",0,"1924-01-01T00:00:00Z",0,"1925-01-01T00:00:00Z",0,"1926-01-01T00:00:00Z",0,"1927-01-01T00:00:00Z",0,"1928-01-01T00:00:00Z",0,"1929-01-01T00:00:00Z",0,"1930-01-01T00:00:00Z",0,"1931-01-01T00:00:00Z",0,"1932-01-01T00:00:00Z",0,"1933-01-01T00:00:00Z",0,"1934-01-01T00:00:00Z",0,"1935-01-01T00:00:00Z",0,"1936-01-01T00:00:00Z",0,"1937-01-01T00:00:00Z",0,"1938-01-01T00:00:00Z",0,"1939-01-01T00:00:00Z",0,"1940-01-01T00:00:00Z",0,"1941-01-01T00:00:00Z",0,"1942-01-01T00:00:00Z",0,"1943-01-01T00:00:00Z",0,"1944-01-01T00:00:00Z",0,"1945-01-01T00:00:00Z",0,"1946-01-01T00:00:00Z",0,"1947-01-01T00:00:00Z",0,"1948-01-01T00:00:00Z",0,"1949-01-01T00:00:00Z",0,"1950-01-01T00:00:00Z",0,"1951-01-01T00:00:00Z",0,"1952-01-01T00:00:00Z",0,"1953-01-01T00:00:00Z",0,"1954-01-01T00:00:00Z",0,"1955-01-01T00:00:00Z",0,"1956-01-01T00:00:00Z",0,"1957-01-01T00:00:00Z",0,"1958-01-01T00:00:00Z",0,"1959-01-01T00:00:00Z",0,"1960-01-01T00:00:00Z",0,"1961-01-01T00:00:00Z",0,"1962-01-01T00:00:00Z",0,"1963-01-01T00:00:00Z",0,"1964-01-01T00:00:00Z",0,"1965-01-01T00:00:00Z",0,"1966-01-01T00:00:00Z",0,"1967-01-01T00:00:00Z",0,"1968-01-01T00:00:00Z",0,"1969-01-01T00:00:00Z",0,"1970-01-01T00:00:00Z",0,"1971-01-01T00:00:00Z",0,"1972-01-01T00:00:00Z",0,"1973-01-01T00:00:00Z",0,"1974-01-01T00:00:00Z",0,"1975-01-01T00:00:00Z",0,"1976-01-01T00:00:00Z",0,"1977-01-01T00:00:00Z",0,"1978-01-01T00:00:00Z",0,"1979-01-01T00:00:00Z",0,"1980-01-01T00:00:00Z",0,"1981-01-01T00:00:00Z",0,"1982-01-01T00:00:00Z",0,"1983-01-01T00:00:00Z",0,"1984-01-01T00:00:00Z",0,"1985-01-01T00:00:00Z",0,"1986-01-01T00:00:00Z",0,"1987-01-01T00:00:00Z",0,"1988-01-01T00:00:00Z",0,"1989-01-01T00:00:00Z",0,"1990-01-01T00:00:00Z",0,"1991-01-01T00:00:00Z",0,"1992-01-01T00:00:00Z",0,"1993-01-01T00:00:00Z",0,"1994-01-01T00:00:00Z",0,"1995-01-01T00:00:00Z",0,"1996-01-01T00:00:00Z",0,"1997-01-01T00:00:00Z",0,"1998-01-01T00:00:00Z",0,"1999-01-01T00:00:00Z",0,"2000-01-01T00:00:00Z",0,"2001-01-01T00:00:00Z",0,"2002-01-01T00:00:00Z",0,"2003-01-01T00:00:00Z",0,"2004-01-01T00:00:00Z",0,"2005-01-01T00:00:00Z",0,"2006-01-01T00:00:00Z",0,"2007-01-01T00:00:00Z",0,"2008-01-01T00:00:00Z",0,"2009-01-01T00:00:00Z",0,"2010-01-01T00:00:00Z",0,"2011-01-01T00:00:00Z",0,"2012-01-01T00:00:00Z",
[jira] [Created] (SOLR-5953) Analysis not correctly shown when using also HTMLStripCharFilterFactory
Zaccheo Bagnati created SOLR-5953:
-
Summary: Analysis not correctly shown when using also
HTMLStripCharFilterFactory
Key: SOLR-5953
URL: https://issues.apache.org/jira/browse/SOLR-5953
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Zaccheo Bagnati
Priority: Minor
When analyzing a field with only HTMLStripCharFilterFactory and
StandardTokenizerFactory, the analysis page doesn't show output for
StandardTokenizerFactory even if json response seems to be correct.
To reproduce:
This is the schema:
id
test
Go to analysis page, choose "testhtml" field and insert "a b" in Field Value
(Index).
The output shown for HTMLSCF is correct ("a b"), but nothing is shown in the
output of ST.
If you choose "test" field, with only ST, it works as expected.
The json, inspected with firebug, seems correct, I think it is only a graphical
issue.
--
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
