[jira] Commented: (SOLR-498) Make it easier to debug new plugin code in an IDE
[ https://issues.apache.org/jira/browse/SOLR-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576442#action_12576442 ] Benson Margulies commented on SOLR-498: --- Let me try to draw a clearer picture here of what I had in mind. I'm sitting here in front of eclipse. It automatically rewrites .class files to whatever folder I tell it to as I make changes. Now, pace run-jetty-run, here's what I've been doing. 1) I made a shell script to launch the example with the usual -X arguments to allow a debugger to attach. 2) Every time I made a change, I used the Eclipse jar exporter to package the classes into a jar in solr/lib. 3) Then cycle jetty and attach Eclipse. By no means am I proposing that a more complex delivery mechanism is appropriate for production use. This is all about the edit-deploy-debug cycle, such as it is. I confess that even with the hints on the user list, I still haven't managed to get solr running from eclipse with run-jetty-run. I can't seem to round up the right jar files in the classpath, and I seem to have hit a bug in run-jetty-run related to using Eclipse workspace links. Having written all this, I think we should abandon this as an issue. I will eventually sort out RJR, and when I do I'll look for a place on your Wiki to record a detailed recipe. > Make it easier to debug new plugin code in an IDE > - > > Key: SOLR-498 > URL: https://issues.apache.org/jira/browse/SOLR-498 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.2 >Reporter: Benson Margulies > > I'm developing components to be deployed via schema.xml. I happen to use > Eclipse, but I think that comparable fates await the users of other IDEs. > I tried, and failed, to find a way to incorporate my eclipse output directory > into the appropriate classpath for schema.xml files. > Putting it into the global jetty classpath via the jetty startup config does > not work, due to webapp class loader delegation rules. > It would be really delux if there were a config file somewhere that would > allow me to add directories that occur in the same class loader's classpath > as the solr/lib directory. > It would be nearly as delux if solr merely supported solr/classes, so that I > could point Eclipse there. -- 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: solrTimeout.patch This patch adds a "timeallowed" parameter which takes a time out value in milliseconds. On a timeout, an exception is thrown from the searcher which results in a 500 error page with the time out exception message. I'd like to add support to return partial results, but I haven't done that part yet. > 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 >Priority: Minor > Attachments: 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] Created: (SOLR-502) Add search time out support
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 Priority: Minor 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-498) Make it easier to debug new plugin code in an IDE
[ https://issues.apache.org/jira/browse/SOLR-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576353#action_12576353 ] Hoss Man commented on SOLR-498: --- from a developers perspective, the overhead of running "jar cf solr/lib/myjar.jar classes/*" seems trival compared to the actual compilation of the java code plus the restarting of the servlet container (or at a minimum: reloading the war) so it hardly seems worthwhile for the debuging case. if someone wants to submit a patch to allow more customizable configuration of the plugin classloader, i won't object -- but it seems unnecessary to me. jars are a very clean way to package plugins, and having a single lib directory for holding them is simple and easy to understand. > Make it easier to debug new plugin code in an IDE > - > > Key: SOLR-498 > URL: https://issues.apache.org/jira/browse/SOLR-498 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.2 >Reporter: Benson Margulies > > I'm developing components to be deployed via schema.xml. I happen to use > Eclipse, but I think that comparable fates await the users of other IDEs. > I tried, and failed, to find a way to incorporate my eclipse output directory > into the appropriate classpath for schema.xml files. > Putting it into the global jetty classpath via the jetty startup config does > not work, due to webapp class loader delegation rules. > It would be really delux if there were a config file somewhere that would > allow me to add directories that occur in the same class loader's classpath > as the solr/lib directory. > It would be nearly as delux if solr merely supported solr/classes, so that I > could point Eclipse there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
BM25 & field-configurable similarity ?
I've been searching a little the Web & Lucene threads about a BM25 similarity (or any "better" one than tf/idf) but I can't tell whether/when it has been/will be implemented (lucene-965). One of the difficulties for BM25 itself seems to lie in its in need for the average document length (length as a number of tokens) as a parameter which is not one of the statistics readily available (idf, tf, numDocs are). It seems possible within Solr to keep some statistics per field fairly easily; if we were to keep up to date the sum of number of tokens per field (hooking add/delete/... operations), since we know the number of documents, it would make this average easy to compute and so would BM25. Since Solr already uses its "own" files (schema/config/multicore) and that a SolrCore is always involved in all operations, book-keeping/serializing those statistics should not be an issue (at least a smaller issue than changing Lucene index serialization or generalizing payloads imho...). On the Similarity itself, my current understanding is that the only methods that would need to change from the DefaultSimilarity are idf() and tf(); can anyone confirm this ? I noticed that there is already a SolrSimilarity class that is not used but could certainly be harnessed to carry the statistics around and/or allow per-field similarity instantiation (adding a "similarity" in the Field configuration) . Does it make (any) sense to try implementing this within Solr or should I just forget about this ? As a more general note, does it make sense to try to use Solr as a "research" playground for similarities instead of Lucene? Or is this the "wrong" level (aka Lucene being a better one)? -- View this message in context: http://www.nabble.com/BM25---field-configurable-similarity---tp15901233p15901233.html Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Updated: (SOLR-501) /admin/analysis.jsp does not decode input string as UTF-8 sequence.
[
https://issues.apache.org/jira/browse/SOLR-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiroaki Kawai updated SOLR-501:
---
Attachment: header.jsp.patch
> /admin/analysis.jsp does not decode input string as UTF-8 sequence.
> ---
>
> Key: SOLR-501
> URL: https://issues.apache.org/jira/browse/SOLR-501
> Project: Solr
> Issue Type: Bug
> Components: web gui
> Environment: Tomcat6.0
>Reporter: Hiroaki Kawai
> Attachments: header.jsp.patch
>
>
> In servlet2.5, we should call
> HttpRequestServlet.setCharacterEncoding("UTF-8") to get a UTF-8 character
> sequence via request.getParameter() in JSP.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-501) /admin/analysis.jsp does not decode input string as UTF-8 sequence.
/admin/analysis.jsp does not decode input string as UTF-8 sequence.
---
Key: SOLR-501
URL: https://issues.apache.org/jira/browse/SOLR-501
Project: Solr
Issue Type: Bug
Components: web gui
Environment: Tomcat6.0
Reporter: Hiroaki Kawai
In servlet2.5, we should call HttpRequestServlet.setCharacterEncoding("UTF-8")
to get a UTF-8 character sequence via request.getParameter() in JSP.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-500) protect analysis.jsp from unexpected null values in tokens
[ https://issues.apache.org/jira/browse/SOLR-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-500. --- Resolution: Fixed I just committed this. Thanks Benson! > protect analysis.jsp from unexpected null values in tokens > -- > > Key: SOLR-500 > URL: https://issues.apache.org/jira/browse/SOLR-500 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 1.3 >Reporter: Benson Margulies > Attachments: soldifs > > > I am about to attach a patch for analysis.jsp that avoids crashing if a field > of a Token happens to be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-500) protect analysis.jsp from unexpected null values in tokens
[ https://issues.apache.org/jira/browse/SOLR-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated SOLR-500: -- Attachment: soldifs Improved patch. > protect analysis.jsp from unexpected null values in tokens > -- > > Key: SOLR-500 > URL: https://issues.apache.org/jira/browse/SOLR-500 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 1.3 >Reporter: Benson Margulies > Attachments: soldifs > > > I am about to attach a patch for analysis.jsp that avoids crashing if a field > of a Token happens to be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-500) protect analysis.jsp from unexpected null values in tokens
[ https://issues.apache.org/jira/browse/SOLR-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated SOLR-500: -- Attachment: (was: soldifs) > protect analysis.jsp from unexpected null values in tokens > -- > > Key: SOLR-500 > URL: https://issues.apache.org/jira/browse/SOLR-500 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 1.3 >Reporter: Benson Margulies > Attachments: soldifs > > > I am about to attach a patch for analysis.jsp that avoids crashing if a field > of a Token happens to be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
