[jira] Issue Comment Edited: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600191#action_12600191 ] timmsc edited comment on SOLR-502 at 5/27/08 9:55 AM: - * Added Javadoc note that a timeallowed param =0 (or omitted) results in no timeout. * Fixed the CamelCase: timeallowed = timeAllowed * Removed the System.out.println(...) statements. bq. I see This should only be called using either filterList or filter, but not both., but I don't see a check for that. Should there be a test for the two vars? This comment was copied from the existing getDocListC method (without the timeAllowed parameter). If there should be a sanity check there, it should probably be added as a separate JIRA issue. was (Author: timmsc): * Added Javadoc note that a timeallowed param =0 (or omitted) results in no timeout. * Fixed the CamelCase: timeallowed = timeAllowed * Removed the System.out.println(...) statements. bq. I see This should only be called using either filterList or filter, but not both., but I don't see a check for that. Should there be a test for the two vars? bq. This comment was copied from the existing getDocListC method (without the timeAllowed parameter). If there should be a sanity check there, it should probably be added as a separate JIRA issue. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502-solrj.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: SOLR-502.patch * Added Javadoc note that a timeallowed param =0 (or omitted) results in no timeout. * Fixed the CamelCase: timeallowed = timeAllowed * Removed the System.out.println(...) statements. bq. I see This should only be called using either filterList or filter, but not both., but I don't see a check for that. Should there be a test for the two vars? bq. This comment was copied from the existing getDocListC method (without the timeAllowed parameter). If there should be a sanity check there, it should probably be added as a separate JIRA issue. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502-solrj.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600196#action_12600196 ] Sean Timm commented on SOLR-502: bq. SOLR-502-solrj.patch is just an old patch that we can really remove so it doesn't confuse anyone, correct? Yes, this is an old patch which can be removed. The solrTimeout.patch files could be removed as well if they are found to be confusing. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502-solrj.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600217#action_12600217 ] Oleg Gnatovskiy commented on SOLR-572: -- Did you guys change the required URL parameters structure? I am hitting the following URL: http://localhost:8983/solr/select/?q=pizzaspellcheck=truespellcheck.dictionary=default and I am getting a nullpointer exception. The config is the one from the sample, and I am using the latest patch. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-502: --- Attachment: (was: SOLR-502-solrj.patch) Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600248#action_12600248 ] Shalin Shekhar Mangar commented on SOLR-502: I've removed the SOLR-502-solrj.patch as per the above comments. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Solr Wiki] Update of SolrTomcat by NoblePaul
: + : + Setting Solr Home from web.xml of solr web app 1) is this really Tomcat specific? I thought this could be done with any servlet container? 2) while this is another way to specify the Solr Home using JNDI, It doesn't seem right to classify this as Configuring because it requires people to muck with the war ... which makes upgrading harder. i would prefer to keep this info off the wiki, or move it somewhere where it's more clear that it's only for people who really wnat to HACK on the solr war. (commented out in the web.xml like path-prefix perhaps?) Either way, i'm moving the info within SolrTomcat for the time being ... it was inserted in between an example context file and the notes about the example. -Hoss
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[
https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600269#action_12600269
]
Otis Gospodnetic commented on SOLR-572:
---
I haven't applied/tried the latest patch yet, but maybe it's
quicker/better to ask here. I'm wondering/worried about the case
where the input is a multi-term query string and a subset (e.g. 2 of 5
terms) of the query terms is misspelled.
For example, what happens when the query is:
london brigge is fallinge down
(my 2 year old's current hit)
In this case the suggestions should be:
# brigge = bridge
# fallinge = falling (or fall, more likely)
Is there something in the response that will allow the client to
figure out the positioning of the spelling suggestions and piece
together the ideal alternative query, in this case london bridge is
falling/fall down?
Ideally, the client could piece the new query string, so that it can, for
example, italicize the misspelled words (see Google's DYM). If the current
SCRH returns the final corrected string, e.g. london bridge is falling down
the client has no easy/accurate way of figuring out what was changed, I think.
If the SCRH returned some mark-up that told the client which word(s) changed,
then the client could do something with those changed words, e.g. london
bridge{was:brigge}
Or, if that has problems, maybe each word should be returned separately and
sequentially:
word=london/ !-- unchanged --
word=briggebridge/word
or maybe with offset info:
word=london offset=0/ !-- unchanged --
word=brigge offset=6bridge/word
Thoughts?
Spell Checker as a Search Component
---
Key: SOLR-572
URL: https://issues.apache.org/jira/browse/SOLR-572
Project: Solr
Issue Type: New Feature
Components: spellchecker
Affects Versions: 1.3
Reporter: Shalin Shekhar Mangar
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.3
Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch
Expose the Lucene contrib SpellChecker as a Search Component. Provide the
following features:
* Allow creating a spell index on a given field and make it possible to have
multiple spell indices -- one for each field
* Give suggestions on a per-field basis
* Given a multi-word query, give only one consistent suggestion
* Process the query with the same analyzer specified for the source field and
process each token separately
* Allow the user to specify minimum length for a token (optional)
Consistency criteria for a multi-word query can consist of the following:
* Preserve the correct words in the original query as it is
* Never give duplicate words in a suggestion
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600272#action_12600272 ] Oleg Gnatovskiy commented on SOLR-572: -- Hello. I am hitting http://localhost:8983/solr/select/?q=pizzaspellcheck=truespellcheck.dictionary=defaultspellcheck.build=true when trying to build the dictionary. My config looks this this: searchComponent name=spellcheck class=org.apache.solr.handler.component.SpellCheckComponent lst name=defaults !-- omp = Only More Popular -- str name=spellcheck.onlyMorePopularfalse/str !-- exr = Extended Results -- str name=spellcheck.extendedResultsfalse/str !-- The number of suggestions to return -- str name=spellcheck.count1/str /lst lst name=spellchecker str name=classnameorg.apache.solr.spelling.IndexBasedSpellChecker/str str name=namedefault/str str name=fieldTypetext_ws/str str name=indexDir/usr/local/apache/lucene/solr1home/solr/data/spellchecker/str /lst lst name=spellchecker str name=classnameorg.apache.solr.spelling.FileBasedSpellChecker/str str name=nameexternal/str str name=sourceLocationspellings.txt/str str name=fieldTypetext_ws/str str name=characterEncodingUTF-8/str str name=indexDir/usr/local/apache/lucene/solr1home/solr/data/spellchecker/str /lst /searchComponent And the NPE is: SEVERE: java.lang.NullPointerException at org.apache.solr.util.HighFrequencyDictionary.init(HighFrequencyDictionary.java:48) at org.apache.solr.spelling.IndexBasedSpellChecker.loadLuceneDictionary(IndexBasedSpellChecker.java:103) at org.apache.solr.spelling.IndexBasedSpellChecker.build(IndexBasedSpellChecker.java:84) at org.apache.solr.handler.component.SpellCheckComponent.prepare(SpellCheckComponent.java:133) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:132) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:125) at org.apache.solr.core.SolrCore.execute(SolrCore.java:965) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:339) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:274) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600275#action_12600275 ] Grant Ingersoll commented on SOLR-572: -- I'm working on it. Will have a new patch soon. -- Grant Ingersoll http://www.lucidimagination.com Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600277#action_12600277 ] Oleg Gnatovskiy commented on SOLR-572: -- Is it an actual error, or was I missing something? Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600275#action_12600275 ] gsingers edited comment on SOLR-572 at 5/27/08 2:06 PM: --- I'm working on it. Will have a new patch soon. was (Author: gsingers): I'm working on it. Will have a new patch soon. -- Grant Ingersoll http://www.lucidimagination.com Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600279#action_12600279 ] Oleg Gnatovskiy commented on SOLR-572: -- In response to Ottis, I don't think each word should be returned individually. In fact it should probably return the entire phrase, with the suggestions inserted. I believe that is what google does. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600279#action_12600279 ] oleg_gnatovskiy edited comment on SOLR-572 at 5/27/08 2:09 PM: --- In response to Ottis, I don't think each word should be returned individually. In fact it should probably return the entire phrase, with the suggestions inserted. I believe that is what google does. Although I guess if the words are returned sequentially, you can easily reform the phrase, so that works too... was (Author: oleg_gnatovskiy): In response to Ottis, I don't think each word should be returned individually. In fact it should probably return the entire phrase, with the suggestions inserted. I believe that is what google does. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600281#action_12600281 ] Otis Gospodnetic commented on SOLR-236: --- It's amazing this issue/patch has so many votes and watchers, yet it's stuck... Ryan, Yonik, Emmanuel, Doug, Charles, Karsten I think Bojan is onto something here. Isn't the ability to *chain QueryComponent (QC) and CollapseComponent (CC) essential*? I'm looking at field_collapsing_dsteigerwald.diff and see that the *CC.prepare method there is identical to the QC.prepare method*, while process methods are different. Could we solve this particular copy/paste situation by *making CC extend QC and simply override the process method*? As for chaining, could CC take the same approach as the MLT Component, which simply does it's thing to find more like this docs and stuffs them into the moreLikeThis element in the response? I could be misunderstanding something, so please correct me if I'm wrong. I'd love to get this one in 1.3 -- it's been waiting in JIRA for too long. :) Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Assignee: Otis Gospodnetic Attachments: field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600279#action_12600279 ] oleg_gnatovskiy edited comment on SOLR-572 at 5/27/08 2:30 PM: --- In response to Otis, I don't think each word should be returned individually. In fact it should probably return the entire phrase, with the suggestions inserted. I believe that is what google does. Although I guess if the words are returned sequentially, you can easily reform the phrase, so that works too... was (Author: oleg_gnatovskiy): In response to Ottis, I don't think each word should be returned individually. In fact it should probably return the entire phrase, with the suggestions inserted. I believe that is what google does. Although I guess if the words are returned sequentially, you can easily reform the phrase, so that works too... Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600283#action_12600283 ] Grant Ingersoll commented on SOLR-572: -- All you see from Googs is their frontend, so who knows what their spell checker does. I think we should return the words individually, the application is responsible for doing the sewing together of the new string, IMO. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600284#action_12600284 ] Oleg Gnatovskiy commented on SOLR-572: -- Should we return suggestions only for the misspelled words, or should we echo the correctly spelled ones as well? Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Add SolrCore.getSolrCore() to SolrServlet.doGet to work arround Resin bug?
Over a year ago, Ryan noticed that Resin wasn't correctly loading the SolrDispatchFilter prior to the SolrServlet in violation of the Servlet Spec... https://issues.apache.org/jira/browse/SOLR-166?focusedCommentId=12474310#action_12474310 ...at the time, the only downside of this was a weird error which was easily dealt with usingsome more robust error handling. However, with the addition of the multicore code to SolrDispatchFilter, the result now is that... 1) SolrServlet.init() calls SolrCore.getSolrCore() 1.1) SolrCore.getSolrCore() sees no singleton, so it constructs a new instance and sets the singleton 1.2) SolrServlet stores the result in a member variable core 2) SolrDispatchFilter.init calls new SolrCore(...) 2.1) the constructor for SolrCore sets the singleton (per previous discussion about how two best support legacy uses of the singleton in a multicore world: it's always the newest core) 3) SolrServlet.doGet uses it's private core, which is now differnet then what SolrDispatchFilter is using. Meanwhile, the legacy SolrUpdateServlet winds up getting the current singleton for every request. ...it seems like a simple fix to try and make things more correct (regardless of what order things are loaded in) would be to either... a) remove the getSolrCore() call in SolrServlet.init() and replace the core member variable with a new call to getSolrCore() at the start of doGet(). OR b) Leave the getSolrCore() call in SolrServlet.init(), but still replace the core member variable with a new call to getSolrCore() at the start of doGet(). Option (a) would insure that only one core ever exists, regardless of which order the various classes are initalied in, as long as the Filter was initialized before the first request to SolrServlet -- but that first request might be slower for legacy users of SolrServlet. Option (b) would garuntee that at least one core was initialzed before the first request so it would be just as fast for legacy users of SolrServlet, at the expensive of initializing (and then ignoring) an extra SolrCore. Either appraoch would ensure that SolrServlet was at least consistent with SolrUpdateServlet (and SolrDispatchFilter) in always using the current singleton core. thoughts? -Hoss
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600294#action_12600294 ] Otis Gospodnetic commented on SOLR-572: --- Right, Google only shows you the final output, not what they do in the backend. But the fact that they italicize misspelled words tells us they have a mechanism that allows the front end to identify them. So I think our task here is to figure out the best/easiest way for the client to identify misspelled words and offer the alternative query to the end user. I think what I outlined above will do that for us: * output all words sequentially * mark the words that are misspelled - it may be best to return the original word plus corrected word: word=london/ !-- unchanged -- word=briggebridge/word or maybe with offset info: word=london offset=0/ !-- unchanged -- word=brigge offset=6bridge/word It's also fine to (*also*) return the final corrected string that doesn't mark the corrected words in any way, and let the lazy clients just use that. Grant or Shalin, will either of you be adding this? Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Add SolrCore.getSolrCore() to SolrServlet.doGet to work arround Resin bug?
I think I'd prefer to have that single core instance and a slower first request instead of doing extra initialization work and then letting extra instances linger... seems cleaner. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Chris Hostetter [EMAIL PROTECTED] To: Solr Dev solr-dev@lucene.apache.org Sent: Tuesday, May 27, 2008 6:27:18 PM Subject: Add SolrCore.getSolrCore() to SolrServlet.doGet to work arround Resin bug? Over a year ago, Ryan noticed that Resin wasn't correctly loading the SolrDispatchFilter prior to the SolrServlet in violation of the Servlet Spec... https://issues.apache.org/jira/browse/SOLR-166?focusedCommentId=12474310#action_12474310 ...at the time, the only downside of this was a weird error which was easily dealt with usingsome more robust error handling. However, with the addition of the multicore code to SolrDispatchFilter, the result now is that... 1) SolrServlet.init() calls SolrCore.getSolrCore() 1.1) SolrCore.getSolrCore() sees no singleton, so it constructs a new instance and sets the singleton 1.2) SolrServlet stores the result in a member variable core 2) SolrDispatchFilter.init calls new SolrCore(...) 2.1) the constructor for SolrCore sets the singleton (per previous discussion about how two best support legacy uses of the singleton in a multicore world: it's always the newest core) 3) SolrServlet.doGet uses it's private core, which is now differnet then what SolrDispatchFilter is using. Meanwhile, the legacy SolrUpdateServlet winds up getting the current singleton for every request. ...it seems like a simple fix to try and make things more correct (regardless of what order things are loaded in) would be to either... a) remove the getSolrCore() call in SolrServlet.init() and replace the core member variable with a new call to getSolrCore() at the start of doGet(). OR b) Leave the getSolrCore() call in SolrServlet.init(), but still replace the core member variable with a new call to getSolrCore() at the start of doGet(). Option (a) would insure that only one core ever exists, regardless of which order the various classes are initalied in, as long as the Filter was initialized before the first request to SolrServlet -- but that first request might be slower for legacy users of SolrServlet. Option (b) would garuntee that at least one core was initialzed before the first request so it would be just as fast for legacy users of SolrServlet, at the expensive of initializing (and then ignoring) an extra SolrCore. Either appraoch would ensure that SolrServlet was at least consistent with SolrUpdateServlet (and SolrDispatchFilter) in always using the current singleton core. thoughts? -Hoss
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[
https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600320#action_12600320
]
Grant Ingersoll commented on SOLR-572:
--
{quote}
Grant or Shalin, will either of you be adding this?
{quote}
Yes, I am working on it.
Spell Checker as a Search Component
---
Key: SOLR-572
URL: https://issues.apache.org/jira/browse/SOLR-572
Project: Solr
Issue Type: New Feature
Components: spellchecker
Affects Versions: 1.3
Reporter: Shalin Shekhar Mangar
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.3
Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch
Expose the Lucene contrib SpellChecker as a Search Component. Provide the
following features:
* Allow creating a spell index on a given field and make it possible to have
multiple spell indices -- one for each field
* Give suggestions on a per-field basis
* Given a multi-word query, give only one consistent suggestion
* Process the query with the same analyzer specified for the source field and
process each token separately
* Allow the user to specify minimum length for a token (optional)
Consistency criteria for a multi-word query can consist of the following:
* Preserve the correct words in the original query as it is
* Never give duplicate words in a suggestion
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600323#action_12600323 ] Oleg Gnatovskiy commented on SOLR-572: -- I am still confused about my NPE. Was that a config issue on my part, or was it a bug? The way Grant said he was working on it, I assumed that it was a bug :-) Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-572) Spell Checker as a Search Component
On May 27, 2008, at 8:25 PM, Oleg Gnatovskiy (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600323 #action_12600323 ] Oleg Gnatovskiy commented on SOLR-572: -- I am still confused about my NPE. Was that a config issue on my part, or was it a bug? The way Grant said he was working on it, I assumed that it was a bug :-) Sorry, I meant I was working on the token alignment issue. I will look at this, too, though. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600326#action_12600326 ] Grant Ingersoll commented on SOLR-572: -- Your field is null for your Lucene configuration. You need to specify: str name=fieldfieldName/str You have fieldType instead. -Grant Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one consistent suggestion * Process the query with the same analyzer specified for the source field and process each token separately * Allow the user to specify minimum length for a token (optional) Consistency criteria for a multi-word query can consist of the following: * Preserve the correct words in the original query as it is * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Wiki loading time
On May 26, 2008, at 12:30 PM, Chris Hostetter wrote: : content). Didn't we look into converting to Confluence at one point in time? Ryan was looking into it, and had an example up ... but i think there may have been a momentum issue (it was right before xmas as i recall). Ryan? I looked at it, and like it. The one thing I needed was a someone with some credentials to try changing the template... (it was just before new years) but then i got distracted and busy... We were considering using it for our main site -- that way each release could have documentation bundled with it. Perhaps the custom stylesheet on javadoc is a better solution to this problem though. For caching, confluence takes a static snapshot of everything. For example: http://cwiki.apache.org/confluence/display/SOLRxSITE/SearchHandler http://cwiki.apache.org/SOLRxSITE/searchhandler.html I'd like to continue looking at this, perhaps it will gain momentum (post 1.3 however) ryan
Re: [Solr Wiki] Update of SolrTomcat by NoblePaul
1) This is not tomcat specific 2) The other options we have are not as easy as this (at least for a casual user). The most common means of deploying an app in tomcat is dropping the war file in the webapps folder. And the most common place to put in JNDI variables is web.xml 3) The documentation must be there in the wiki. Let us decide on where to keep it. --Noble On Wed, May 28, 2008 at 1:34 AM, Chris Hostetter [EMAIL PROTECTED] wrote: : + : + Setting Solr Home from web.xml of solr web app 1) is this really Tomcat specific? I thought this could be done with any servlet container? 2) while this is another way to specify the Solr Home using JNDI, It doesn't seem right to classify this as Configuring because it requires people to muck with the war ... which makes upgrading harder. i would prefer to keep this info off the wiki, or move it somewhere where it's more clear that it's only for people who really wnat to HACK on the solr war. (commented out in the web.xml like path-prefix perhaps?) Either way, i'm moving the info within SolrTomcat for the time being ... it was inserted in between an example context file and the notes about the example. -Hos
Re: Wiki loading time
So would you suggest creating all new documentation on Confluence or there are tools to migrate stuff existing on MoinMoin? On Wed, May 28, 2008 at 9:16 AM, Ryan McKinley [EMAIL PROTECTED] wrote: On May 26, 2008, at 12:30 PM, Chris Hostetter wrote: : content). Didn't we look into converting to Confluence at one point in time? Ryan was looking into it, and had an example up ... but i think there may have been a momentum issue (it was right before xmas as i recall). Ryan? I looked at it, and like it. The one thing I needed was a someone with some credentials to try changing the template... (it was just before new years) but then i got distracted and busy... We were considering using it for our main site -- that way each release could have documentation bundled with it. Perhaps the custom stylesheet on javadoc is a better solution to this problem though. For caching, confluence takes a static snapshot of everything. For example: http://cwiki.apache.org/confluence/display/SOLRxSITE/SearchHandler http://cwiki.apache.org/SOLRxSITE/searchhandler.html I'd like to continue looking at this, perhaps it will gain momentum (post 1.3 however) ryan -- Regards, Shalin Shekhar Mangar.
Re: [Solr Wiki] Update of SolrTomcat by NoblePaul
On Tue, May 27, 2008 at 1:04 PM, Chris Hostetter [EMAIL PROTECTED] wrote: : + : + Setting Solr Home from web.xml of solr web app 1) is this really Tomcat specific? I thought this could be done with any servlet container? 2) while this is another way to specify the Solr Home using JNDI, It doesn't seem right to classify this as Configuring because it requires people to muck with the war ... which makes upgrading harder. FWIW, Tomcat *does* support mechanisms to configure JNDI resources (including the Solr Home setting) *without* modifying the WAR file itself. Indeed, that was really the motivation behind having JNDI resources in the first place. Two easy approaches: * Define the Context element, including nested resource settings for JNDI) in Tomcat's server.xml file. This isn't deploy-on-demand, but is perfectly reasonable for a production environment. * Using the manager app, deploy a context.xml file (including pointers to the war and the JNDI settings) instead of deploying a war directly. See the manager webapp docs for more info. i would prefer to keep this info off the wiki, or move it somewhere where it's more clear that it's only for people who really wnat to HACK on the solr war. (commented out in the web.xml like path-prefix perhaps?) So you want to *hide* information that some users will find useful? That doesn't seem very user friendly :-). Either way, i'm moving the info within SolrTomcat for the time being ... it was inserted in between an example context file and the notes about the example. -Hoss Craig McClanahan
Re: [Solr Wiki] Update of SolrTomcat by NoblePaul
: 2) The other options we have are not as easy as this (at least for a : casual user). The most common means of deploying an app in tomcat is : dropping the war file in the webapps folder. And the most common place : to put in JNDI variables is web.xml the casual user should not have to unwar and edit the web.xml -- particularly since doing so is something that would then need to be done on every upgrade -- that's what context fragments in tomcat are for. Bottom line: the web.xml is not a configuration file, In general, users shouldn't need to worry about it's existence unless they wnat to (as experienced java users. : 3) The documentation must be there in the wiki. Let us decide on where : to keep it. A new Hacking Solr page perhaps? -Hoss
Re: [Solr Wiki] Update of SolrTomcat by NoblePaul
: FWIW, Tomcat *does* support mechanisms to configure JNDI resources : (including the Solr Home setting) *without* modifying the WAR file : itself. Indeed, that was really the motivation behind having JNDI : resources in the first place. Two easy approaches: ...well, yeah ... no ones disputing that. Context based JNDI declarations have been documented on teh wiki for a long time ... i'm specificly questioning the recent addition suggesting that unpacking the war and editing the web.xml as a way to configure the Solr Home. : i would prefer to keep this info off the wiki, or move it somewhere where : it's more clear that it's only for people who really wnat to HACK on the : solr war. (commented out in the web.xml like path-prefix perhaps?) : So you want to *hide* information that some users will find useful? : That doesn't seem very user friendly :-). neither is suggesting that people need to find the web.xml for their app ... i'm not suggesting we hide anything, i'm saying that the typical Solr user should not be expected to understand what or where a web.xml is. The type of user that is that might want to set JNDI properties directly in the web.xml is a) going to be looking at the web.xml; and b) probably already going to know that's possible to set arbitrary JNDI props that way without us telling them -- general documenting about declaring the Solr Home using JNDI (which we have) is enough. Our advanced users who get how WARs work don't need info like this, and it can only confuse our novice users who don't know (and don't want to know) that much about the internals of a WAR. -Hoss
Re: [Solr Wiki] Update of SolrTomcat by NoblePaul
On Wed, May 28, 2008 at 10:13 AM, Chris Hostetter [EMAIL PROTECTED] wrote: : FWIW, Tomcat *does* support mechanisms to configure JNDI resources : (including the Solr Home setting) *without* modifying the WAR file : itself. Indeed, that was really the motivation behind having JNDI : resources in the first place. Two easy approaches: ...well, yeah ... no ones disputing that. Context based JNDI declarations have been documented on teh wiki for a long time ... i'm specificly questioning the recent addition suggesting that unpacking the war and editing the web.xml as a way to configure the Solr Home. This probably is very good for production (server.xml). Those who deploy it in production are not novice users. In my general experience I have seen people deploying applications in Tomcat by dropping in a war or by exploding the .war file into webapps folder. General tomcat users are more familiar with web.xml than server.xml. So, this is a very useful information for that class of users and this info was absent. : i would prefer to keep this info off the wiki, or move it somewhere where : it's more clear that it's only for people who really wnat to HACK on the : solr war. (commented out in the web.xml like path-prefix perhaps?) : So you want to *hide* information that some users will find useful? : That doesn't seem very user friendly :-). neither is suggesting that people need to find the web.xml for their app ... i'm not suggesting we hide anything, i'm saying that the typical Solr user should not be expected to understand what or where a web.xml is. The type of user that is that might want to set JNDI properties directly in the web.xml is a) going to be looking at the web.xml; and b) probably already going to know that's possible to set arbitrary JNDI props that way without us telling them -- general documenting about declaring the Solr Home using JNDI (which we have) is enough. I am still not convinced that people get confused by seeing that there are more than one ways of setting JNDI properties in a webapp. But, they do not know the exact syntax for adding one. (I myself googled to figure it out, though I knew it was possible). Hence the documentation. Our advanced users who get how WARs work don't need info like this, and it can only confuse our novice users who don't know (and don't want to know) that much about the internals of a WAR. -Hoss
[jira] Created: (SOLR-584) XSL for stats.jsp ignores core
XSL for stats.jsp ignores core Key: SOLR-584 URL: https://issues.apache.org/jira/browse/SOLR-584 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Hoss Man Priority: Trivial Fix For: 1.3 stats.xsl doesn't do anything with the core info from the XML, so it gets dumped unceremoniously into the middle of the page. this is particulrly disconcerting in single core mode when the value is null (which should probably be changed in stats.jsp to something that seems less like an error) http://www.nabble.com/%22null%22-in-admin-page-to17486312.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
