Re: Changing Logging in Solr to Apache Commons Logging
: as I see in the source code, Solr uses JDK-Logging. How about changing : that to Apache Commons Logging? What would be the motivations for making such a change? you may also want to review this recent related thread... http://www.nabble.com/Re%3A-logging---slf4j--p9369105.html -Hoss
Changing Logging in Solr to Apache Commons Logging
Hi everybody, as I see in the source code, Solr uses JDK-Logging. How about changing that to Apache Commons Logging? Best regards, Max Hütter -- Maximilian Hütter blue elephant systems GmbH Wollgrasweg 49 D-70599 Stuttgart Tel: (+49) 0711 - 45 10 17 578 Fax: (+49) 0711 - 45 10 17 573 e-mail : [EMAIL PROTECTED] Sitz : Stuttgart, Amtsgericht Stuttgart, HRB 24106 Geschäftsführer: Joachim Hörnle, Thomas Gentsch, Holger Dietrich
[jira] Commented: (SOLR-199) N-gram
[ https://issues.apache.org/jira/browse/SOLR-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485065 ] Otis Gospodnetic commented on SOLR-199: --- While I was the one who started that n-gram approach, and while I'm saving code and config changes from that work "just in case", I'm not sure why we'd add it to Solr at this point, if nothing is going to use it. I'd say keep the patch here, so one can easily put that back into Solr when a need arises, but don't commit it unless there is some immediate need. Do you have something that needs the n-gram stuff in Solr? > N-gram > -- > > Key: SOLR-199 > URL: https://issues.apache.org/jira/browse/SOLR-199 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Adam Hiatt >Priority: Trivial > Attachments: SOLR-81-ngram.patch > > > This tracks the creation of a patch that adds the n-gram/edge n-gram > tokenizing functionality that was initially part of SOLR-81 (spell checking). > This was taken out b/c the lucene SpellChecker class removed this dependency. > None-the-less, I think this is useful functionality and the addition is > trivial. How does everyone feel about such an addition? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-199) N-gram
[ https://issues.apache.org/jira/browse/SOLR-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hiatt updated SOLR-199: Attachment: SOLR-81-ngram.patch Here is the patch. > N-gram > -- > > Key: SOLR-199 > URL: https://issues.apache.org/jira/browse/SOLR-199 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Adam Hiatt >Priority: Trivial > Attachments: SOLR-81-ngram.patch > > > This tracks the creation of a patch that adds the n-gram/edge n-gram > tokenizing functionality that was initially part of SOLR-81 (spell checking). > This was taken out b/c the lucene SpellChecker class removed this dependency. > None-the-less, I think this is useful functionality and the addition is > trivial. How does everyone feel about such an addition? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-199) N-gram
N-gram -- Key: SOLR-199 URL: https://issues.apache.org/jira/browse/SOLR-199 Project: Solr Issue Type: New Feature Components: search Reporter: Adam Hiatt Priority: Trivial This tracks the creation of a patch that adds the n-gram/edge n-gram tokenizing functionality that was initially part of SOLR-81 (spell checking). This was taken out b/c the lucene SpellChecker class removed this dependency. None-the-less, I think this is useful functionality and the addition is trivial. How does everyone feel about such an addition? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-197) ContentStream +Reader and Utility classes
[ https://issues.apache.org/jira/browse/SOLR-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-197: --- Attachment: SOLR-197-ContentStreamReader.patch Added parameters for: stream.contentType stream.file stream.file uses a FileReader unless a charset is specified. see discussion on: http://www.nabble.com/charset-specification-for-input-streams-tf3470788.html > ContentStream +Reader and Utility classes > - > > Key: SOLR-197 > URL: https://issues.apache.org/jira/browse/SOLR-197 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Fix For: 1.2 > > Attachments: SOLR-197-ContentStreamReader.patch, > SOLR-197-ContentStreamReader.patch > > > In parsing content streams, it is often easier to deal with a Reader. > This patch adds getReader() to ContentStream > This patch also > * moves ContentStream to o.a.s.util - This class is needed for SOLR-20 and > should be eventually be in a separate .jar (SOLR-135) > * Adds three concrete ContentStream implementations: File/URL/String > * Adds documentation > * test cases for File/URL/String -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-198) RunExecutableListener always waits for the subprocess completion regardless of wait="false"
[
https://issues.apache.org/jira/browse/SOLR-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-198:
Attachment: RunExecutableListener.java.diff
> RunExecutableListener always waits for the subprocess completion regardless
> of wait="false"
> ---
>
> Key: SOLR-198
> URL: https://issues.apache.org/jira/browse/SOLR-198
> Project: Solr
> Issue Type: Bug
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: RunExecutableListener.java.diff
>
>
> Although the type of the value of "wait" attribute is boolean in
> solrconfig.xml:
>
> snapshooter
> solr/bin
> false
>arg1 arg2
>MYVAR=val1
>
> RunExecutableListener trys to get the value as a string:
> if ("false".equals(args.get("wait"))) wait=false;
> therefore, it always waits for the subprocess completion, even if you set
> wait="false" . The above line would probably be like this:
> if (Boolean.FALSE.equals(args.get("wait"))) wait=false;
> regards,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-198) RunExecutableListener always waits for the subprocess completion regardless of wait="false"
RunExecutableListener always waits for the subprocess completion regardless of
wait="false"
---
Key: SOLR-198
URL: https://issues.apache.org/jira/browse/SOLR-198
Project: Solr
Issue Type: Bug
Reporter: Koji Sekiguchi
Priority: Minor
Although the type of the value of "wait" attribute is boolean in solrconfig.xml:
snapshooter
solr/bin
false
arg1 arg2
MYVAR=val1
RunExecutableListener trys to get the value as a string:
if ("false".equals(args.get("wait"))) wait=false;
therefore, it always waits for the subprocess completion, even if you set
wait="false" . The above line would probably be like this:
if (Boolean.FALSE.equals(args.get("wait"))) wait=false;
regards,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
