[jira] [Created] (SOLR-5276) highlighter working using stemmed tokens from another field and text from another
Maciej Lizewski created SOLR-5276: - Summary: highlighter working using stemmed tokens from another field and text from another Key: SOLR-5276 URL: https://issues.apache.org/jira/browse/SOLR-5276 Project: Solr Issue Type: Improvement Components: highlighter Reporter: Maciej Lizewski Priority: Minor The case is like this: I have 'content' field with content extracted with tika and several fields for language versions (like content_pl, content_en, content_es, content_ru, etc). I also use custom langid component which can copy 'content' to serveral content_* fields if it detects more than one language (so those parts are properly stemmed in every language present in text). Now to use highlighter in such scenario I need to store all those language fields even if their contents is always same as the one in 'content' field. Would be nice if I could configure language specific fields to be not stored, and configure highlighter to take tokens positions from those fields and apply them to text in 'content' field... In other words - to say: take tokens from 'content_pl', and prepare highlight based on text in 'content' field. It could be administrator responsibility to guarantee that mapped fields have same content. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4841) DetectedLanguage constructor should be public
[ https://issues.apache.org/jira/browse/SOLR-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662013#comment-13662013 ] Maciej Lizewski commented on SOLR-4841: --- I am OK with that. My point was that it is impossible to extend LanguageIdentifierUpdateProcessor with own custom implementation, because constructor does not have any visibility modifier, so it is accessible only from same package. > DetectedLanguage constructor should be public > - > > Key: SOLR-4841 > URL: https://issues.apache.org/jira/browse/SOLR-4841 > Project: Solr > Issue Type: Bug >Reporter: Maciej Lizewski > > org.apache.solr.update.processor.DetectedLanguage constructor should be > public. Without that it is impossible to create owne class extending > LanguageIdentifierUpdateProcessor. > LanguageIdentifierUpdateProcessor base class needs detectLanguage(String > content) function to return listy of DetectedLanguage's but you cannot create > such objects because constructor is accessible only in same package > (org.apache.solr.update.processor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4841) DetectedLanguage constructor should be public
Maciej Lizewski created SOLR-4841: - Summary: DetectedLanguage constructor should be public Key: SOLR-4841 URL: https://issues.apache.org/jira/browse/SOLR-4841 Project: Solr Issue Type: Bug Reporter: Maciej Lizewski org.apache.solr.update.processor.DetectedLanguage constructor should be public. Without that it is impossible to create owne class extending LanguageIdentifierUpdateProcessor. LanguageIdentifierUpdateProcessor base class needs detectLanguage(String content) function to return listy of DetectedLanguage's but you cannot create such objects because constructor is accessible only in same package (org.apache.solr.update.processor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633907#comment-13633907 ] Maciej Lizewski commented on LUCENE-2899: - why don't you prepare this as separate project that produces some jars and config files with instructions on how to add it in solr configuration instead of publishing all changes as patches to solr sources? I am interested in doing some tests with your library but setting all things up seems quite complicated and hard to maintain in future... it is just a thought. > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.3 > > Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, > LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, > LUCENE-2899-RJN.patch, OpenNLPFilter.java, OpenNLPTokenizer.java, > opennlp_trunk.patch > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4562) core selector not working in Chrome
[ https://issues.apache.org/jira/browse/SOLR-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maciej Lizewski resolved SOLR-4562. --- Resolution: Not A Problem > core selector not working in Chrome > --- > > Key: SOLR-4562 > URL: https://issues.apache.org/jira/browse/SOLR-4562 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.2 >Reporter: Maciej Lizewski > Attachments: Przechwytywanie.PNG > > > after fresh installation of Solr 4.2 on windows 7 64bit > I do not see any cores in Google Chrome to select in combobox. Also - when > trying to prepare URI by hand - I see error that there is no such core. In > FireFox - there is default 'collection1' core visible without problems. > My Chrome version: 26.0.1410.28 beta-m > I cannot se any errors in JS console... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4562) core selector not working in Chrome
[ https://issues.apache.org/jira/browse/SOLR-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13600352#comment-13600352 ] Maciej Lizewski commented on SOLR-4562: --- You were right. After clearing browser cache everything is working ok. Sorry for duplicate issue - I search for something similar but did not found that one. funny thing is that earlier I tried refreshing page with SHIFT which *should* reload all resources from server... :) > core selector not working in Chrome > --- > > Key: SOLR-4562 > URL: https://issues.apache.org/jira/browse/SOLR-4562 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.2 >Reporter: Maciej Lizewski > Attachments: Przechwytywanie.PNG > > > after fresh installation of Solr 4.2 on windows 7 64bit > I do not see any cores in Google Chrome to select in combobox. Also - when > trying to prepare URI by hand - I see error that there is no such core. In > FireFox - there is default 'collection1' core visible without problems. > My Chrome version: 26.0.1410.28 beta-m > I cannot se any errors in JS console... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4562) core selector not working in Chrome
Maciej Lizewski created SOLR-4562: - Summary: core selector not working in Chrome Key: SOLR-4562 URL: https://issues.apache.org/jira/browse/SOLR-4562 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Maciej Lizewski after fresh installation of Solr 4.2 on windows 7 64bit I do not see any cores in Google Chrome to select in combobox. Also - when trying to prepare URI by hand - I see error that there is no such core. In FireFox - there is default 'collection1' core visible without problems. My Chrome version: 26.0.1410.28 beta-m I cannot se any errors in JS console... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4562) core selector not working in Chrome
[ https://issues.apache.org/jira/browse/SOLR-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maciej Lizewski updated SOLR-4562: -- Attachment: Przechwytywanie.PNG > core selector not working in Chrome > --- > > Key: SOLR-4562 > URL: https://issues.apache.org/jira/browse/SOLR-4562 > Project: Solr > Issue Type: Bug >Affects Versions: 4.2 >Reporter: Maciej Lizewski > Attachments: Przechwytywanie.PNG > > > after fresh installation of Solr 4.2 on windows 7 64bit > I do not see any cores in Google Chrome to select in combobox. Also - when > trying to prepare URI by hand - I see error that there is no such core. In > FireFox - there is default 'collection1' core visible without problems. > My Chrome version: 26.0.1410.28 beta-m > I cannot se any errors in JS console... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-2416) Solr Cell fails to index Zip file contents
[ https://issues.apache.org/jira/browse/SOLR-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546719#comment-13546719 ] Maciej Lizewski edited comment on SOLR-2416 at 1/8/13 9:10 AM: --- I think this is really needed feature. Also in earlier versions of Solr it worked different than now: grepping code of org.apache.solr.handler.extraction.ExtractingDocumentLoader from version 1.4.0.1 show that context was not created and instead autoDetectParser::parse function was called with 3 parameters (without context) and this caused context to be automatically created with Parser=autoDetectParser... this is backward compatibility violation after adding PasswordProvider. Also comments in current code suggest that someone was not sure about consequences of such change: "TODO: should we design a way to pass in parse context?" the patch is already attached as I see... was (Author: redguy666): I think this is really needed feature. Also in earlier versions of Solr it worked different than now: grepping code of org.apache.solr.handler.extraction.ExtractingDocumentLoader from version 1.4.0.1 show that context was not created and instead autoDetectParser::parse function was called with 3 parameters (without context) and this caused context to be automatically created with Parser=autoDetectParser... this is backward compatibility violation after adding PasswordProvider. Also comments in current code suggest that someone was not sure about consequences of such change: "TODO: should we design a way to pass in parse context?" the patch is already attached as I see... anyway - does anyone have this handler refactored as external jar so it can be added to running solr instance without changing and recompiling core libs? > Solr Cell fails to index Zip file contents > -- > > Key: SOLR-2416 > URL: https://issues.apache.org/jira/browse/SOLR-2416 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler, contrib - Solr Cell (Tika > extraction) >Affects Versions: 1.4.1 >Reporter: Jayendra Patil > Fix For: 5.0 > > Attachments: SOLR-2416_ExtractingDocumentLoader.patch > > > Working with the latest Solr Trunk code and seems the Tika handlers for Solr > Cell (ExtractingDocumentLoader.java) and Data Import handler > (TikaEntityProcessor.java) fails to index the zip file contents again. > It just indexes the file names again. > This issue was addressed some time back, late last year, but seems to have > reappeared with the latest code. > Jira for the Data Import handler part with the patch and the testcase - > https://issues.apache.org/jira/browse/SOLR-2332. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2416) Solr Cell fails to index Zip file contents
[ https://issues.apache.org/jira/browse/SOLR-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546719#comment-13546719 ] Maciej Lizewski commented on SOLR-2416: --- I think this is really needed feature. Also in earlier versions of Solr it worked different than now: grepping code of org.apache.solr.handler.extraction.ExtractingDocumentLoader from version 1.4.0.1 show that context was not created and instead autoDetectParser::parse function was called with 3 parameters (without context) and this caused context to be automatically created with Parser=autoDetectParser... this is backward compatibility violation after adding PasswordProvider. Also comments in current code suggest that someone was not sure about consequences of such change: "TODO: should we design a way to pass in parse context?" the patch is already attached as I see... anyway - does anyone have this handler refactored as external jar so it can be added to running solr instance without changing and recompiling core libs? > Solr Cell fails to index Zip file contents > -- > > Key: SOLR-2416 > URL: https://issues.apache.org/jira/browse/SOLR-2416 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler, contrib - Solr Cell (Tika > extraction) >Affects Versions: 1.4.1 >Reporter: Jayendra Patil > Fix For: 5.0 > > Attachments: SOLR-2416_ExtractingDocumentLoader.patch > > > Working with the latest Solr Trunk code and seems the Tika handlers for Solr > Cell (ExtractingDocumentLoader.java) and Data Import handler > (TikaEntityProcessor.java) fails to index the zip file contents again. > It just indexes the file names again. > This issue was addressed some time back, late last year, but seems to have > reappeared with the latest code. > Jira for the Data Import handler part with the patch and the testcase - > https://issues.apache.org/jira/browse/SOLR-2332. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
