[jira] Commented: (SOLR-162) lucene index browser / admin helpers (Luke)
[ https://issues.apache.org/jira/browse/SOLR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473874 ] Ryan McKinley commented on SOLR-162: check SOLR-149. it adds the path to a request and prints it out with the log. > lucene index browser / admin helpers (Luke) > --- > > Key: SOLR-162 > URL: https://issues.apache.org/jira/browse/SOLR-162 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-162-Admin-XML-luke.patch > > > Luke (http://www.getopt.org/luke/) is a great tool to help learn / understand > / debug lucene indexes. > Solr already does a lot of what luke does... but it could do a bit more. > Specifically: > * browse top terms across all fields (similar to faceting) > * browse lucene documents / properties directly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-149) Make solr more embeddable
[ https://issues.apache.org/jira/browse/SOLR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-149: --- Attachment: SOLR-149-embeddable.patch adding the path to the request context so handlers can use it and we can make a nice debug string > Make solr more embeddable > - > > Key: SOLR-149 > URL: https://issues.apache.org/jira/browse/SOLR-149 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-149-embeddable.patch, SOLR-149-embeddable.patch, > SOLR-149-embeddable.patch > > > With a few simple changes, solr can be an easily embedded in a custom jetty > app. > With this patch, one can run solr from the jar file using: > server = new Server( port ); > > // Initalize home (without JNDI) > Config.setInstanceDir(home); > > // Initalize the servlets > Context root = new Context( server, "/", Context.SESSIONS ); > root.addServlet( SolrServlet.class, "/select" ); > root.addServlet( SolrUpdateServlet.class, "/update" ); > root.addFilter( SolrDispatchFilter.class, "*", Handler.REQUEST ); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-86) [PATCH] standalone updater cli based on httpClient
[ https://issues.apache.org/jira/browse/SOLR-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473872 ] Erik Hatcher commented on SOLR-86: -- Wow, so much great stuff happening in the Solr system! I'd love to have this tool built-in for my Solr workshop coming up. Hoss, you game for committing this since you assigned it to yourself? Or if you want I'd be happy to add it. > [PATCH] standalone updater cli based on httpClient > --- > > Key: SOLR-86 > URL: https://issues.apache.org/jira/browse/SOLR-86 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Thorsten Scherler > Assigned To: Hoss Man > Attachments: simple-post-tool-2007-02-15.patch, > simple-post-tool-2007-02-16.patch, > simple-post-using-urlconnection-approach.patch, solr-86.diff, solr-86.diff > > > We need a cross platform replacement for the post.sh. > The attached code is a direct replacement of the post.sh since it is actually > doing the same exact thing. > In the future one can extend the CLI with other feature like auto commit, > etc.. > Right now the code assumes that SOLR-85 is applied since we using the servlet > of this issue to actually do the update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SOLR-160) [Patch] Get Test Solr Server working in Windows environment
Mel, I think I might have fixed the test_bad_connection issue you encountered. Errno exceptions are platform specific and I simply loosed the test to look for ::Exception (Solr::Exception gets in the way, requiring :: prefix, I believe). As for test_ping - I dunno. If you cd solr; java -jar start.jar, what do you get from going to http://localhost:8983/admin/ping ?? I get this: Response::Ping checks if its ok like this: @ok = REXML::XPath.first(@doc, './solr/ping') ? true : false You could experiment with REXML::XPath to see if you can get this working for you. Let us know what you discover. Erik On Feb 13, 2007, at 11:26 PM, Mel Riffe (JIRA) wrote: [Patch] Get Test Solr Server working in Windows environment --- Key: SOLR-160 URL: https://issues.apache.org/jira/browse/SOLR-160 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Environment: Windows XP Home Reporter: Mel Riffe Attachments: win32_functional_tests.patch, win32_functional_tests.results Because Windows does not support forking processes I created a patch that uses the Win32 api to create and destroy a process to control the test solr server. I have attached two files: 1) the patch and 2) the results from running 'rake test' In my environment I have two failures. My approach was to still support the including/requiring of the single file test/functional/test_solr_server.rb and have it further require the platform dependent start/stop api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-160) [Patch] Get Test Solr Server working in Windows environment
[ https://issues.apache.org/jira/browse/SOLR-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473870 ] Erik Hatcher commented on SOLR-160: --- Mel - I've applied a slight variation on your patch that inlines the conditional implementation all within the test server file instead of two additional files being needed. I'm seeing 100% code passage here. Your mileage still varies? > [Patch] Get Test Solr Server working in Windows environment > --- > > Key: SOLR-160 > URL: https://issues.apache.org/jira/browse/SOLR-160 > Project: Solr > Issue Type: Improvement > Components: clients - ruby - flare > Environment: Windows XP Home >Reporter: Mel Riffe > Attachments: win32_functional_tests.patch, > win32_functional_tests.results > > > Because Windows does not support forking processes I created a patch that > uses the Win32 api to create and destroy a process to control the test solr > server. > I have attached two files: 1) the patch and 2) the results from running 'rake > test' In my environment I have two failures. > My approach was to still support the including/requiring of the single file > test/functional/test_solr_server.rb and have it further require the platform > dependent start/stop api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-163) libxml/rexml-related test case failure
libxml/rexml-related test case failure -- Key: SOLR-163 URL: https://issues.apache.org/jira/browse/SOLR-163 Project: Solr Issue Type: Bug Components: clients - ruby - flare Reporter: Erik Hatcher http://www.nabble.com/solrb-testing--tf3213880.html#a8949745 1) Failure: test_delete_by_i18n_query_request(DeleteTest) [./test/unit/ delete_test.rb:53]: <"\n ëäïöü\n"> expected to be =~ [\s]*\303\253\303\244\303\257\303\266\303\274<\/ query>[\s]*<\/delete>/m>. 2) Failure: test_i18n_xml(FieldTest) [./test/unit/field_test.rb:39]: <"Äêâîôû Öëäïöü"> expected to be =~ \303\204\303\252\303\242\303\256\303 \264\303\273 \303\226\303\253\303\244\303\257\303\266\303\274<\/ field>/m>. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-162) lucene index browser / admin helpers (Luke)
[ https://issues.apache.org/jira/browse/SOLR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473865 ] Erik Hatcher commented on SOLR-162: --- This is truly great stuff, Ryan! *whew* I can't keep up. I did however become really intrigued by this particular patch and tried it out. I like all these details and Flare will certainly leverage this stuff deeply. One comment. for this request http://localhost:/solr/admin/ping?wt=ruby&indent=on all that was logged was this: Feb 16, 2007 8:59:22 PM org.apache.solr.core.SolrCore execute INFO: wt=ruby&indent=on 0 8 I realize this is tangentially related to this issue, and nothing introduced with this patch, but I'd like to see the path (admin/ping, in this case) in the log as well so that requests could be recreated easily. I'm used to the solr/select? stuff and tacking on what I get in the log file, but with the newly revamped mega flexible paths, it'd be handy to see the path here. > lucene index browser / admin helpers (Luke) > --- > > Key: SOLR-162 > URL: https://issues.apache.org/jira/browse/SOLR-162 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-162-Admin-XML-luke.patch > > > Luke (http://www.getopt.org/luke/) is a great tool to help learn / understand > / debug lucene indexes. > Solr already does a lot of what luke does... but it could do a bit more. > Specifically: > * browse top terms across all fields (similar to faceting) > * browse lucene documents / properties directly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: patches patches and more patches
No impact for anyone unless they build their own .war or run from a .jar http://issues.apache.org/jira/browse/SOLR-14 by SOLR-14, i really mean SOLR-149 I have one of these damn keyboards that don't type
patches patches and more patches
Wow, what can I say... you continue to out pace us committers, Ryan. I'll try and look at at least *one* of the open issues this weekend. thanks! I just checked over the patches to make sure i won't waste you time. When you do get a change to look them over, here is a little guide to what would be the most useful (for me) to have committed / get feedback Trivial / quick to check: http://issues.apache.org/jira/browse/SOLR-85 http://issues.apache.org/jira/browse/SOLR-142 No impact for anyone unless they build their own .war or run from a .jar http://issues.apache.org/jira/browse/SOLR-14 The 'updateable' command needs a good code review before going forward. It is works well for everything i need it to do (so far). http://issues.apache.org/jira/browse/SOLR-149 If you only look at one, take a look at 149 thanks ryan
[jira] Updated: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-139: --- Attachment: SOLR-139-IndexDocumentCommand.patch added missing files. this should is ready to check over if anyone has some time > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley > Attachments: SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-XmlUpdater.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- 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-162) lucene index browser / admin helpers (Luke)
Wow indeed! Go Ryan. On Feb 16, 2007, at 6:07 PM, Yonik Seeley (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-162? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12473849 ] Yonik Seeley commented on SOLR-162: --- Wow, what can I say... you continue to out pace us committers, Ryan. I'll try and look at at least *one* of the open issues this weekend. lucene index browser / admin helpers (Luke) --- Key: SOLR-162 URL: https://issues.apache.org/jira/browse/SOLR-162 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley Priority: Minor Attachments: SOLR-162-Admin-XML-luke.patch Luke (http://www.getopt.org/luke/) is a great tool to help learn / understand / debug lucene indexes. Solr already does a lot of what luke does... but it could do a bit more. Specifically: * browse top terms across all fields (similar to faceting) * browse lucene documents / properties directly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-81) Add Query Spellchecker functionality
[ https://issues.apache.org/jira/browse/SOLR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473848 ] Adam Hiatt commented on SOLR-81: What was the bug? I couldn't tell from the Lucene issue description. > Add Query Spellchecker functionality > > > Key: SOLR-81 > URL: https://issues.apache.org/jira/browse/SOLR-81 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Otis Gospodnetic >Priority: Minor > Attachments: SOLR-81-edgengram-ngram.patch, > SOLR-81-ngram-schema.patch, SOLR-81-ngram.patch > > > Use the simple approach of n-gramming outside of Solr and indexing n-gram > documents. For example: > > lettuce > let > let ett ttu tuc uce > uce > lett > lett ettu ttuc tuce > tuce > > See: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01254.html > Java clients: SOLR-20 (add delete commit optimize), SOLR-30 (search) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-162) lucene index browser / admin helpers (Luke)
[ https://issues.apache.org/jira/browse/SOLR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473849 ] Yonik Seeley commented on SOLR-162: --- Wow, what can I say... you continue to out pace us committers, Ryan. I'll try and look at at least *one* of the open issues this weekend. > lucene index browser / admin helpers (Luke) > --- > > Key: SOLR-162 > URL: https://issues.apache.org/jira/browse/SOLR-162 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-162-Admin-XML-luke.patch > > > Luke (http://www.getopt.org/luke/) is a great tool to help learn / understand > / debug lucene indexes. > Solr already does a lot of what luke does... but it could do a bit more. > Specifically: > * browse top terms across all fields (similar to faceting) > * browse lucene documents / properties directly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: RequestHandler -> XML/JSON/etc. response?
: Are spelling suggestions going to be a separate request to Solr or : would it all be within the desired request handler output, such that : they could be incorporated into DisMax or Standard request handler : output? i think Otis is tackling hte use case where the Solr index models a dictionary -- each doc is a single "word" with fields containing various ngrams of that word, and other properties about how/why it might be a good suggestion. -Hoss
[jira] Updated: (SOLR-162) lucene index browser / admin helpers (Luke)
[ https://issues.apache.org/jira/browse/SOLR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-162: --- Attachment: SOLR-162-Admin-XML-luke.patch This patch moves a lot of the /admin jsp pages to SolrRequestHandlers and adds a LukeRequestHandler to let you browse a lucene index (even if it does not match the solr schema). I don't know XSLT well enough to make anything look good yet, but with an ok XSLT file, we could replace many of the .jsp files. pages of interest: http://localhost:8983/solr/admin/ http://localhost:8983/solr/admin/file http://localhost:8983/solr/admin/file?file=solrconfig.xml http://localhost:8983/solr/admin/threads http://localhost:8983/solr/admin/registry http://localhost:8983/solr/admin/registry?wt=json&indent=true http://localhost:8983/solr/admin/stats http://localhost:8983/solr/admin/ping http://localhost:8983/solr/admin/properties http://localhost:8983/solr/admin/properties?name=java.home http://localhost:8983/solr/admin/logging http://localhost:8983/solr/admin/logging?set=FINE http://localhost:8983/solr/admin/luke (field info + top fields) http://localhost:8983/solr/admin/luke?field=cat (like faceting) http://localhost:8983/solr/admin/luke?docID=10 (lucene doc + solr doc) http://localhost:8983/solr/admin/luke?id=10 (lucene doc + solr doc) http://localhost:8983/solr/admin/luke?id=MA147LL/A > lucene index browser / admin helpers (Luke) > --- > > Key: SOLR-162 > URL: https://issues.apache.org/jira/browse/SOLR-162 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-162-Admin-XML-luke.patch > > > Luke (http://www.getopt.org/luke/) is a great tool to help learn / understand > / debug lucene indexes. > Solr already does a lot of what luke does... but it could do a bit more. > Specifically: > * browse top terms across all fields (similar to faceting) > * browse lucene documents / properties directly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: RequestHandler -> XML/JSON/etc. response?
On Feb 16, 2007, at 4:28 PM, Ryan McKinley wrote: On 2/16/07, Erik Hatcher <[EMAIL PROTECTED]> wrote: from SolrDispatchFilter, we have this: QueryResponseWriter responseWriter = core.getQueryResponseWriter(solrReq); response.setContentType(responseWriter.getContentType (solrReq, solrRsp)); PrintWriter out = response.getWriter(); responseWriter.write(out, solrReq, solrRsp); This is how the output gets written as XML (or Ruby in my case, &wt=ruby :). But the SolrRequestHandler author does not need to worry about pushing the output into various formats - that all happens automatically. Right... I was just giving Otis some details on how the magic happened. Erik
Re: RequestHandler -> XML/JSON/etc. response?
On 2/16/07, Erik Hatcher <[EMAIL PROTECTED]> wrote: from SolrDispatchFilter, we have this: QueryResponseWriter responseWriter = core.getQueryResponseWriter(solrReq); response.setContentType(responseWriter.getContentType (solrReq, solrRsp)); PrintWriter out = response.getWriter(); responseWriter.write(out, solrReq, solrRsp); This is how the output gets written as XML (or Ruby in my case, &wt=ruby :). But the SolrRequestHandler author does not need to worry about pushing the output into various formats - that all happens automatically. You just need to dump results into the SolrQueryResponse and they will be written out appropriately. The values you can put in (without extending all the ResponseWriters) are: * Collection * Object[] * Document (lucene) * Map * standard types (int/float/string) etc * everything else gets added as object.toString()
Re: RequestHandler -> XML/JSON/etc. response?
why not just the standard list format so we don't have to write new parsers :)
List suggestions = new ArrayList();
suggestions.add( "suggestion 1" );
suggestions.add( "suggestion 2" );
suggestions.add( "suggestion 3" );
suggestions.add( "suggestion 4" );
rsp.add( "suggestions", suggestions );
gives:
suggestion 1
suggestion 2
suggestion 3
suggestion 4
or:
"suggestions":[
"suggestion 1",
"suggestion 2",
"suggestion 3",
"suggestion 4"],
we can get the numSuggestions from the array length
ryan
On 2/16/07, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
Hi,
I'm still torturing SOLR-81 - the spellchecker fronted with a Solr
RequestHandler.
Being a RequestHandler virgin, I'm not sure how to go from getting the
alternative
spelling suggestion(s) in the RequestHandler, to the output that might look
something
like this (made it up on the spot, please point out any weaknesses):
Is the response header really needed?
suggestion 1
...
suggestion N
I'm looking at StandardRequestHandler, trying to base y RequestHandler on it,
but I don't see where the results get XML-ified.
I see rsp.add("response",results.docList); and friends, but it's not clear to
me at this crazy hour at night how that makes it to the XMLWriter or XMLResponseWriter,
or some other class that finally spits out XML.
Can somebody please point me in the right direction?
Thanks,
Otis
Re: RequestHandler -> XML/JSON/etc. response?
On Feb 16, 2007, at 3:26 PM, Otis Gospodnetic wrote:
I'm still torturing SOLR-81 - the spellchecker fronted with a Solr
RequestHandler.
Being a RequestHandler virgin, I'm not sure how to go from getting
the alternative
spelling suggestion(s) in the RequestHandler, to the output that
might look something
like this (made it up on the spot, please point out any weaknesses):
Is the response header really needed?
suggestion 1
...
suggestion N
I'm looking at StandardRequestHandler, trying to base y
RequestHandler on it, but I don't see where the results get XML-ified.
I see rsp.add("response",results.docList); and friends, but it's
not clear to me at this crazy hour at night how that makes it to
the XMLWriter or XMLResponseWriter, or some other class that
finally spits out XML.
Can somebody please point me in the right direction?
from SolrDispatchFilter, we have this:
QueryResponseWriter responseWriter =
core.getQueryResponseWriter(solrReq);
response.setContentType(responseWriter.getContentType
(solrReq, solrRsp));
PrintWriter out = response.getWriter();
responseWriter.write(out, solrReq, solrRsp);
This is how the output gets written as XML (or Ruby in my case,
&wt=ruby :).
Are spelling suggestions going to be a separate request to Solr or
would it all be within the desired request handler output, such that
they could be incorporated into DisMax or Standard request handler
output?
Erik
RequestHandler -> XML/JSON/etc. response?
Hi,
I'm still torturing SOLR-81 - the spellchecker fronted with a Solr
RequestHandler.
Being a RequestHandler virgin, I'm not sure how to go from getting the
alternative
spelling suggestion(s) in the RequestHandler, to the output that might look
something
like this (made it up on the spot, please point out any weaknesses):
Is the response header really needed?
suggestion 1
...
suggestion N
I'm looking at StandardRequestHandler, trying to base y RequestHandler on it,
but I don't see where the results get XML-ified.
I see rsp.add("response",results.docList); and friends, but it's not clear to
me at this crazy hour at night how that makes it to the XMLWriter or
XMLResponseWriter, or some other class that finally spits out XML.
Can somebody please point me in the right direction?
Thanks,
Otis
[jira] Commented: (SOLR-81) Add Query Spellchecker functionality
[ https://issues.apache.org/jira/browse/SOLR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473813 ] Otis Gospodnetic commented on SOLR-81: -- Adam: Please look at LUCENE-759. That incorporates your patch, fixes a bug I found in it, and introduces a new bug, so we are not too bored with bug-free code. Any idea how to extract that last n-gram when using Side.BACK? > Add Query Spellchecker functionality > > > Key: SOLR-81 > URL: https://issues.apache.org/jira/browse/SOLR-81 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Otis Gospodnetic >Priority: Minor > Attachments: SOLR-81-edgengram-ngram.patch, > SOLR-81-ngram-schema.patch, SOLR-81-ngram.patch > > > Use the simple approach of n-gramming outside of Solr and indexing n-gram > documents. For example: > > lettuce > let > let ett ttu tuc uce > uce > lett > lett ettu ttuc tuce > tuce > > See: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01254.html > Java clients: SOLR-20 (add delete commit optimize), SOLR-30 (search) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-79) [PATCH] Using system properties in Solr configuration
[
https://issues.apache.org/jira/browse/SOLR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473754
]
Yonik Seeley commented on SOLR-79:
--
Very nice, this will make testing easier as well.
> [PATCH] Using system properties in Solr configuration
> -
>
> Key: SOLR-79
> URL: https://issues.apache.org/jira/browse/SOLR-79
> Project: Solr
> Issue Type: New Feature
>Reporter: Alexander Saar
> Assigned To: Erik Hatcher
>Priority: Minor
> Attachments: solr-config-system-property.patch,
> solr-config-system-property.patch, solr-config-system-property.patch,
> solr-config-system-property.patch, solr-config-system-property.patch,
> solr-config-system-property.patch
>
>
> Actually it is not possible to use system properties for configuring the Solr
> engine. There should be a way of referencing system properties from
> solrconfig.xml, like {$prop.name}.
> The attached patch will provide this feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-79) [PATCH] Using system properties in Solr configuration
[
https://issues.apache.org/jira/browse/SOLR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher resolved SOLR-79.
--
Resolution: Fixed
This feature has been added, complete with the requested exception handling
when a property is not defined and no default value provided.
> [PATCH] Using system properties in Solr configuration
> -
>
> Key: SOLR-79
> URL: https://issues.apache.org/jira/browse/SOLR-79
> Project: Solr
> Issue Type: New Feature
>Reporter: Alexander Saar
> Assigned To: Erik Hatcher
>Priority: Minor
> Attachments: solr-config-system-property.patch,
> solr-config-system-property.patch, solr-config-system-property.patch,
> solr-config-system-property.patch, solr-config-system-property.patch,
> solr-config-system-property.patch
>
>
> Actually it is not possible to use system properties for configuring the Solr
> engine. There should be a way of referencing system properties from
> solrconfig.xml, like {$prop.name}.
> The attached patch will provide this feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (SOLR-79) [PATCH] Using system properties in Solr configuration
[
https://issues.apache.org/jira/browse/SOLR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SOLR-79 started by Erik Hatcher.
> [PATCH] Using system properties in Solr configuration
> -
>
> Key: SOLR-79
> URL: https://issues.apache.org/jira/browse/SOLR-79
> Project: Solr
> Issue Type: New Feature
>Reporter: Alexander Saar
> Assigned To: Erik Hatcher
>Priority: Minor
> Attachments: solr-config-system-property.patch,
> solr-config-system-property.patch, solr-config-system-property.patch,
> solr-config-system-property.patch, solr-config-system-property.patch,
> solr-config-system-property.patch
>
>
> Actually it is not possible to use system properties for configuring the Solr
> engine. There should be a way of referencing system properties from
> solrconfig.xml, like {$prop.name}.
> The attached patch will provide this feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-86) [PATCH] standalone updater cli based on httpClient
[ https://issues.apache.org/jira/browse/SOLR-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-86: Attachment: simple-post-tool-2007-02-16.patch Here's another update of SimplePostTool (simple-post-tool-2007-02-16.patch) with an improved "user interface". In the happy case, the tool reports what it's doing in detail (yes, we could add a "be quiet" switch ;-), checking Solr's responses to decide whether POSTing went well: $ java -jar post.jar http://localhost:8983/solr/update *.xml SimplePostTool: $Id$ SimplePostTool: WARNING: Make sure your XML documents are encoded in UTF-8, other encodings are not currently supported SimplePostTool: POSTing files to http://localhost:8983/solr/update.. SimplePostTool: POSTing file hd.xml SimplePostTool: POSTing file utf8-example.xml SimplePostTool: COMMITting Solr index changes.. SimplePostTool: 2 files POSTed to http://localhost:8983/solr/update $Id$ will be the SVN revision. Solr responses are checked as Strings, this should be improved by parsing them as XML. If the Solr URL does not respond, the error message should help: $ java -jar post.jar http://localhost:8983/solr/update *.xml SimplePostTool: $Id$ SimplePostTool: WARNING: Make sure your XML documents are encoded in UTF-8, other encodings are not currently supported SimplePostTool: POSTing files to http://localhost:8983/solr/update.. SimplePostTool: POSTing file hd.xml SimplePostTool: FATAL: Connection error (is Solr running at http://localhost:8983/solr/update ?): java.net.ConnectException: Connection refused > [PATCH] standalone updater cli based on httpClient > --- > > Key: SOLR-86 > URL: https://issues.apache.org/jira/browse/SOLR-86 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Thorsten Scherler > Assigned To: Hoss Man > Attachments: simple-post-tool-2007-02-15.patch, > simple-post-tool-2007-02-16.patch, > simple-post-using-urlconnection-approach.patch, solr-86.diff, solr-86.diff > > > We need a cross platform replacement for the post.sh. > The attached code is a direct replacement of the post.sh since it is actually > doing the same exact thing. > In the future one can extend the CLI with other feature like auto commit, > etc.. > Right now the code assumes that SOLR-85 is applied since we using the servlet > of this issue to actually do the update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
