[jira] Resolved: (SOLR-118) Some admin pages stop working with error 404 as the only symptom
[ https://issues.apache.org/jira/browse/SOLR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SOLR-118. -- Resolution: Fixed We have confirmed Otis's hypothesis by deleting Jetty's work dir under /tmp while Solr runs, which causes the 404 to appear as described above. I have added this to the Solr FAQ [1], and added Otis to my IOU a glass of milk list. [1] http://wiki.apache.org/solr/FAQ#head-eff0fcf7bd2ef9385999b1b5c71fffb34e568e8b Some admin pages stop working with error 404 as the only symptom -- Key: SOLR-118 URL: https://issues.apache.org/jira/browse/SOLR-118 Project: Solr Issue Type: Bug Components: web gui Environment: Fedora Core 4 (Linux version 2.6.11-1.1369_FC4smp) Sun's JVM 1.5.0_07-b03 Reporter: Bertrand Delacretaz Priority: Minor This was reported to the mailing list a while ago, see http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200610.mbox/[EMAIL PROTECTED] Today I'm seeing the same thing on a Solr instance that has been running since January 9th (about 13 days) with the plain start.jar setup. Index contains 150'000 docs, 88322 search requests to date. $ curl http://localhost:8983/solr/admin/analysis.jsp html head titleError 404 /admin/analysis.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/analysis.jsp/pre pRequestURI=/solr/admin/analysis.jsp/p ... curl http://localhost:8983/solr/admin/index.jsp html head titleError 404 /admin/index.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/index.jsp/pre pRequestURI=/solr/admin/index.jsp/p ... Other admin pages work correctly, for example http://localhost:8983/solr/admin/stats.jsp I don't see any messages in the logs, which are capturing stdout and stderr from the JVM. I guess I'll have to restart this instance, I'm out of possibilities to find out what's happening exactly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-118) Some admin pages stop working with error 404 as the only symptom
[ https://issues.apache.org/jira/browse/SOLR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508253 ] Bertrand Delacretaz commented on SOLR-118: -- Otis, I guess we'll owe you a free beverage of his choice, your guess sounds totally right. According to http://docs.codehaus.org/display/JETTY/Temporary+Directories the easiest fix might be to create a $(jetty.home)/work directory, which Jetty will use. I haven't checked if this works with the Jetty that's embedded with Solr. Some admin pages stop working with error 404 as the only symptom -- Key: SOLR-118 URL: https://issues.apache.org/jira/browse/SOLR-118 Project: Solr Issue Type: Bug Components: web gui Environment: Fedora Core 4 (Linux version 2.6.11-1.1369_FC4smp) Sun's JVM 1.5.0_07-b03 Reporter: Bertrand Delacretaz Priority: Minor This was reported to the mailing list a while ago, see http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200610.mbox/[EMAIL PROTECTED] Today I'm seeing the same thing on a Solr instance that has been running since January 9th (about 13 days) with the plain start.jar setup. Index contains 150'000 docs, 88322 search requests to date. $ curl http://localhost:8983/solr/admin/analysis.jsp html head titleError 404 /admin/analysis.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/analysis.jsp/pre pRequestURI=/solr/admin/analysis.jsp/p ... curl http://localhost:8983/solr/admin/index.jsp html head titleError 404 /admin/index.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/index.jsp/pre pRequestURI=/solr/admin/index.jsp/p ... Other admin pages work correctly, for example http://localhost:8983/solr/admin/stats.jsp I don't see any messages in the logs, which are capturing stdout and stderr from the JVM. I guess I'll have to restart this instance, I'm out of possibilities to find out what's happening exactly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-207) snappuller inefficient finding latest snapshot
[
https://issues.apache.org/jira/browse/SOLR-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488413
]
Bertrand Delacretaz commented on SOLR-207:
--
IIUC the snapshot directories are named like
snapshot.MMDDHHMMSS
and they are all under the same parent directory.
If that's the case, then doing
ls -rt ${data_dir}/snapshot.* | head -1
will return the name of the most recent directory, efficiently.
snappuller inefficient finding latest snapshot
--
Key: SOLR-207
URL: https://issues.apache.org/jira/browse/SOLR-207
Project: Solr
Issue Type: Bug
Components: replication
Reporter: Yonik Seeley
Attachments: find_maxdepth.patch
snapinstaller (and snappuller) do the following to find the latest snapshot:
name=`find ${data_dir} -name snapshot.* -print|grep -v wip|sort -r|head -1`
This recurses into all of the snapshot directories, doing much more disk-io
than is necessary.
I think it is the cause of bloated kernel memory usage we have seen on some
of our Linux boxes, caused
by kernel dentry and inode caches. Those caches compete with buffer cache
(caching the actual data of the index)
and can thus decrease performance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-207) snappuller inefficient finding latest snapshot
[
https://issues.apache.org/jira/browse/SOLR-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488468
]
Bertrand Delacretaz commented on SOLR-207:
--
I think find -maxdepth is not supported on Solaris. And the -t option in my
previous example was obviously wrong.
I'm not sure if ls -r sorts by filename everywhere (but I have no evidence that
it does not).
The most portable version might be
ls ${data_dir} | grep snapshot\\. | grep -v wip | sort -r | head -1
snappuller inefficient finding latest snapshot
--
Key: SOLR-207
URL: https://issues.apache.org/jira/browse/SOLR-207
Project: Solr
Issue Type: Bug
Components: replication
Reporter: Yonik Seeley
Attachments: find_maxdepth.patch
snapinstaller (and snappuller) do the following to find the latest snapshot:
name=`find ${data_dir} -name snapshot.* -print|grep -v wip|sort -r|head -1`
This recurses into all of the snapshot directories, doing much more disk-io
than is necessary.
I think it is the cause of bloated kernel memory usage we have seen on some
of our Linux boxes, caused
by kernel dentry and inode caches. Those caches compete with buffer cache
(caching the actual data of the index)
and can thus decrease performance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-194) SimplePostTool incorrectly uses the current JVM encoding to read files
SimplePostTool incorrectly uses the current JVM encoding to read files -- Key: SOLR-194 URL: https://issues.apache.org/jira/browse/SOLR-194 Project: Solr Issue Type: Bug Components: clients - java Reporter: Bertrand Delacretaz Priority: Minor Using java -Dfile.encoding=iso-8859-1 -jar post.jar http://localhost:8983/solr/update utf8-example.xml posts incorrect data, apparently utf8-example.xml is read using the JVM's encoding. As a workaround before we fix this, use java -Dfile.encoding=UTF-8 -jar post.jar http://localhost:8983/solr/update utf8-example.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-194) SimplePostTool uses hardcoded UTF-8 encoding to read files
[ https://issues.apache.org/jira/browse/SOLR-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-194: - Summary: SimplePostTool uses hardcoded UTF-8 encoding to read files (was: SimplePostTool incorrectly uses the current JVM encoding to read files) SimplePostTool uses hardcoded UTF-8 encoding to read files -- Key: SOLR-194 URL: https://issues.apache.org/jira/browse/SOLR-194 Project: Solr Issue Type: Bug Components: clients - java Reporter: Bertrand Delacretaz Priority: Minor Using java -Dfile.encoding=iso-8859-1 -jar post.jar http://localhost:8983/solr/update utf8-example.xml posts incorrect data, apparently utf8-example.xml is read using the JVM's encoding. As a workaround before we fix this, use java -Dfile.encoding=UTF-8 -jar post.jar http://localhost:8983/solr/update utf8-example.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-194) SimplePostTool uses hardcoded UTF-8 encoding to read files
[ https://issues.apache.org/jira/browse/SOLR-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-194: - Attachment: post.jar Includes the fix of revision 520817 SimplePostTool uses hardcoded UTF-8 encoding to read files -- Key: SOLR-194 URL: https://issues.apache.org/jira/browse/SOLR-194 Project: Solr Issue Type: Bug Components: clients - java Reporter: Bertrand Delacretaz Priority: Minor Attachments: post.jar Using java -Dfile.encoding=iso-8859-1 -jar post.jar http://localhost:8983/solr/update utf8-example.xml posts incorrect data, apparently utf8-example.xml is read using the JVM's encoding. As a workaround before we fix this, use java -Dfile.encoding=UTF-8 -jar post.jar http://localhost:8983/solr/update utf8-example.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481829 ] Bertrand Delacretaz commented on SOLR-84: - Same here, solr-nick.gif is cool! IMHO it just needs something to make the letters stand out a bit more, maybe a bit of thin white spacing around the letter shapes? New Solr logo? -- Key: SOLR-84 URL: https://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, solr-nick.gif, solr.jpg, solr.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-118) Some admin pages stop working with error 404 as the only symptom
[ https://issues.apache.org/jira/browse/SOLR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480010 ] Bertrand Delacretaz commented on SOLR-118: -- I'm seeing another, probably related, problem, on a Solr instance that's been running for 23 days: solr/admin/stats.xsl returns a 404 error, so although solr/admin/stats.jsp returns the correct XML it is not displayed in my browser. It seems like the default servlet (which serves static files) is dead, although the rest works fine. Most probably a Jetty issue. Some admin pages stop working with error 404 as the only symptom -- Key: SOLR-118 URL: https://issues.apache.org/jira/browse/SOLR-118 Project: Solr Issue Type: Bug Components: web gui Environment: Fedora Core 4 (Linux version 2.6.11-1.1369_FC4smp) Sun's JVM 1.5.0_07-b03 Reporter: Bertrand Delacretaz Priority: Minor This was reported to the mailing list a while ago, see http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200610.mbox/[EMAIL PROTECTED] Today I'm seeing the same thing on a Solr instance that has been running since January 9th (about 13 days) with the plain start.jar setup. Index contains 150'000 docs, 88322 search requests to date. $ curl http://localhost:8983/solr/admin/analysis.jsp html head titleError 404 /admin/analysis.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/analysis.jsp/pre pRequestURI=/solr/admin/analysis.jsp/p ... curl http://localhost:8983/solr/admin/index.jsp html head titleError 404 /admin/index.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/index.jsp/pre pRequestURI=/solr/admin/index.jsp/p ... Other admin pages work correctly, for example http://localhost:8983/solr/admin/stats.jsp I don't see any messages in the logs, which are capturing stdout and stderr from the JVM. I guess I'll have to restart this instance, I'm out of possibilities to find out what's happening exactly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479991 ] Bertrand Delacretaz commented on SOLR-69: - Is there a way to get this patch to listen to start rows on the moreLikeThis result section? IIUC you want to use the start rows request parameters to limit the number of results in the moreLikeThis section? This is not implemented currently, and if we did it we'd have to use different parameter names (mlt.start and mlt.rows maybe) so that they don't interfere with the main part of the result set. PATCH:MoreLikeThis support -- Key: SOLR-69 URL: https://issues.apache.org/jira/browse/SOLR-69 Project: Solr Issue Type: Improvement Components: search Reporter: Bertrand Delacretaz Priority: Minor Attachments: lucene-queries-2.0.0.jar, SOLR-69.patch, SOLR-69.patch, SOLR-69.patch Here's a patch that implements simple support of Lucene's MoreLikeThis class. The MoreLikeThisHelper code is heavily based on (hmm...lifted from might be more appropriate ;-) Erik Hatcher's example mentioned in http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html To use it, add at least the following parameters to a standard or dismax query: mlt=true mlt.fl=list,of,fields,which,define,similarity See the MoreLikeThisHelper source code for more parameters. Here are two URLs that work with the example config, after loading all documents found in exampledocs in the index (just to show that it seems to work - of course you need a larger corpus to make it interesting): http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst I haven't tested this extensively yet, will do in the next few days. But comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-190) Encoding declaration of POSTed XML documents is ignored
Encoding declaration of POSTed XML documents is ignored --- Key: SOLR-190 URL: https://issues.apache.org/jira/browse/SOLR-190 Project: Solr Issue Type: Bug Components: update Reporter: Bertrand Delacretaz Priority: Minor Currently, the post.sh script and the SimplePostTool use this header to define encoding: Content-type:text/xml; charset=utf-8 And the XML encoding declaration of the POSTed document is ignored. According to RFC 3023, the correct way would be to use Content-type:application/xml and use the XML document's encoding. One this is fixed, the please use UTF-8 encoding warning is SimplePostTool can be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476002 ] Bertrand Delacretaz commented on SOLR-69: - See Ken Krugler's comments about term vectors at http://www.nabble.com/MoreLikeThis-and-term-vectors---documentation-suggestion-tf3295459.html PATCH:MoreLikeThis support -- Key: SOLR-69 URL: https://issues.apache.org/jira/browse/SOLR-69 Project: Solr Issue Type: Improvement Components: search Reporter: Bertrand Delacretaz Priority: Minor Attachments: lucene-queries-2.0.0.jar, SOLR-69.patch, SOLR-69.patch, SOLR-69.patch Here's a patch that implements simple support of Lucene's MoreLikeThis class. The MoreLikeThisHelper code is heavily based on (hmm...lifted from might be more appropriate ;-) Erik Hatcher's example mentioned in http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html To use it, add at least the following parameters to a standard or dismax query: mlt=true mlt.fl=list,of,fields,which,define,similarity See the MoreLikeThisHelper source code for more parameters. Here are two URLs that work with the example config, after loading all documents found in exampledocs in the index (just to show that it seems to work - of course you need a larger corpus to make it interesting): http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst I haven't tested this extensively yet, will do in the next few days. But comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-173) too many open files with posting to update handler
[ https://issues.apache.org/jira/browse/SOLR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475664 ] Bertrand Delacretaz commented on SOLR-173: -- After making the change shown above in solrconfig.xml, a commit is enough to make the number of open file handles grow: curl http://localhost:8983/solr/update --data-binary 'commit/' -H 'Content-type:text/xml; charset=utf-8' lsof shows that many of these file handles point to files in data/index, which have been deleted during the commit: lsof -p 9563 | grep data/index | wc -l (where 9563 is my solr's process ID) shows 398 file handles after a few commits, although my data/index dir contains only 47 files. So it looks like something is keeping useless open handles to old index files after a commit. too many open files with posting to update handler Key: SOLR-173 URL: https://issues.apache.org/jira/browse/SOLR-173 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Reporter: Ryan McKinley Attachments: SOLR-173-open-files-bug.patch From brian: 1) Download trunk/nightly 2) Change line 347 of example/solr/conf/solrconfig.xml to requestHandler name=/update class=solr.XmlUpdateRequestHandler 3) java -jar start.jar... 3) Run post.sh a bunch of times on the same xml file... (in a shell script or whatever) 4) After a few seconds/minutes jetty will crash with too many open files - - - - - all you've got to do is apache-solr-nightly/example/exampledocs ryan$ while [ 0 -lt 1 ]; do ./post.sh hd.xml; done with the request handler pointing to /update. Use # lsof | grep solr | wc -l to watch the fdescs fly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-164) Use the SOLR-86 client in examples of the Solr tutorial
[ https://issues.apache.org/jira/browse/SOLR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SOLR-164. -- Resolution: Fixed Patch applied in revision 509455. Website updated as per http://wiki.apache.org/solr/Website_Update_HOWTO Use the SOLR-86 client in examples of the Solr tutorial --- Key: SOLR-164 URL: https://issues.apache.org/jira/browse/SOLR-164 Project: Solr Issue Type: Improvement Components: documentation Reporter: Bertrand Delacretaz Priority: Minor Attachments: SOLR-164-patched-tutorial.html, SOLR-164-tutorial.xml.patch I'll attach a patch for the Solr tutorial (http://lucene.apache.org/solr/tutorial.html) to use the java client of SOLR-86 instead of post.sh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-164) Use the SOLR-86 client in examples of the Solr tutorial
[ https://issues.apache.org/jira/browse/SOLR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474389 ] Bertrand Delacretaz commented on SOLR-164: -- I have reverted the website update, as the SOLR-86 client is not available in a released version yet. We'll have to update the site once we do a release. Here's what I did to revert changes on people.apache.org: cd /www/lucene.apache.org/solr svn up -r 509454 tutorial.* Use the SOLR-86 client in examples of the Solr tutorial --- Key: SOLR-164 URL: https://issues.apache.org/jira/browse/SOLR-164 Project: Solr Issue Type: Improvement Components: documentation Reporter: Bertrand Delacretaz Priority: Minor Attachments: SOLR-164-patched-tutorial.html, SOLR-164-tutorial.xml.patch I'll attach a patch for the Solr tutorial (http://lucene.apache.org/solr/tutorial.html) to use the java client of SOLR-86 instead of post.sh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-164) Use the SOLR-86 client in examples of the Solr tutorial
[ https://issues.apache.org/jira/browse/SOLR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SOLR-164. Following discussion on the list, I have re-updated the website. Docs for released versions are distributed with the releases themselves. Use the SOLR-86 client in examples of the Solr tutorial --- Key: SOLR-164 URL: https://issues.apache.org/jira/browse/SOLR-164 Project: Solr Issue Type: Improvement Components: documentation Reporter: Bertrand Delacretaz Priority: Minor Attachments: SOLR-164-patched-tutorial.html, SOLR-164-tutorial.xml.patch I'll attach a patch for the Solr tutorial (http://lucene.apache.org/solr/tutorial.html) to use the java client of SOLR-86 instead of post.sh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-164) Use the SOLR-86 client in examples of the Solr tutorial
Use the SOLR-86 client in examples of the Solr tutorial --- Key: SOLR-164 URL: https://issues.apache.org/jira/browse/SOLR-164 Project: Solr Issue Type: Improvement Components: documentation Reporter: Bertrand Delacretaz Priority: Minor I'll attach a patch for the Solr tutorial (http://lucene.apache.org/solr/tutorial.html) to use the java client of SOLR-86 instead of post.sh -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-164) Use the SOLR-86 client in examples of the Solr tutorial
[ https://issues.apache.org/jira/browse/SOLR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-164: - Attachment: SOLR-164-patched-tutorial.html Attaching the resulting HTML (without CSS) if people want to review it here. Use the SOLR-86 client in examples of the Solr tutorial --- Key: SOLR-164 URL: https://issues.apache.org/jira/browse/SOLR-164 Project: Solr Issue Type: Improvement Components: documentation Reporter: Bertrand Delacretaz Priority: Minor Attachments: SOLR-164-patched-tutorial.html, SOLR-164-tutorial.xml.patch I'll attach a patch for the Solr tutorial (http://lucene.apache.org/solr/tutorial.html) to use the java client of SOLR-86 instead of post.sh -- 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_12474096 ] Bertrand Delacretaz commented on SOLR-86: - Considering the tutorial examples (http://lucene.apache.org/solr/tutorial.html), it'd be useful to allow this to POST its standard input, or the contents of a command-line parameter: Use case: echo deletequeryname:DDR/query/delete | java -jar post.jar http://localhost:8983 or (having both would be useful I think): java -jar post.jar -data deletequeryname:DDR/query/delete http://localhost:8983 [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: Erik Hatcher 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.
[jira] Updated: (SOLR-164) Use the SOLR-86 client in examples of the Solr tutorial
[ https://issues.apache.org/jira/browse/SOLR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-164: - Attachment: SOLR-164-tutorial.xml.patch Patch for the xdocs document, please review before we commit this. Use the SOLR-86 client in examples of the Solr tutorial --- Key: SOLR-164 URL: https://issues.apache.org/jira/browse/SOLR-164 Project: Solr Issue Type: Improvement Components: documentation Reporter: Bertrand Delacretaz Priority: Minor Attachments: SOLR-164-tutorial.xml.patch I'll attach a patch for the Solr tutorial (http://lucene.apache.org/solr/tutorial.html) to use the java client of SOLR-86 instead of post.sh -- 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_12473932
]
Bertrand Delacretaz commented on SOLR-162:
--
I briefly tested this, it looks very useful, and the different RequestHandlers
make the code very modular, way to go!
One nitpick: I'd use system.properties instead of properties, it's more
precise.
And two suggestions related to XSLT transformations for presentation:
1) It'd be good to systematically include in the output XML the class name of
the SolrRequestHandler used. XSLT transforms can then use this info to adapt
themselves to the information being output.
2) It'd be good to name lst elements, as much as possible, also to allow XSLT
transforms to adapt themselves to the content.
For example, using a NamedList instead of an ArralyList in the Now show all
the threads loop in ThreadDumpRequestHandler:
NamedListNamedListObject lst = new NamedListNamedListObject();
for (ThreadInfo ti : tinfos) {
lst.add( thread, getThreadInfo( ti ) );
}
Outputs this:
lst name=thread
long name=id35/long
str name=nameP1-19/str
str name=stateRUNNABLE/str...
where the name=thread attribute can be used to decide how to present the
contents of the lst element.
Thinking about it, we might want to add a datatype attribute to these lists,
to use when presenting them?
lst datatype=java.lang.Thread
would help present all Thread info in a consistent way, no matter where it
comes from.
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-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.
[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-15.patch I have reworked the SimplePostTool, improved the error reporting (less verbose but still informative enough I think), and added example parameters to make it self-explaining. I've also changed build.xml, the post.jar now goes to example/exampledocs, the same place as post.sh. Like the original SimplePostTool, this does not require any additional Java library. I think it's good enough to be a portable replacement for post.sh. [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-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.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467179 ] Bertrand Delacretaz commented on SOLR-69: - Intuitively, without having checked exactly how it's implemented, I think MoreLikeThis queries should work irrelevant of whether fields are stored or not, as it's based on what's indexed. Maybe someone who knows Lucene's internals better than I do can comment. Did you find a case where non-stored fields cause problems? PATCH:MoreLikeThis support -- Key: SOLR-69 URL: https://issues.apache.org/jira/browse/SOLR-69 Project: Solr Issue Type: Improvement Components: search Reporter: Bertrand Delacretaz Priority: Minor Attachments: lucene-queries-2.0.0.jar, SOLR-69.patch, SOLR-69.patch, SOLR-69.patch Here's a patch that implements simple support of Lucene's MoreLikeThis class. The MoreLikeThisHelper code is heavily based on (hmm...lifted from might be more appropriate ;-) Erik Hatcher's example mentioned in http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html To use it, add at least the following parameters to a standard or dismax query: mlt=true mlt.fl=list,of,fields,which,define,similarity See the MoreLikeThisHelper source code for more parameters. Here are two URLs that work with the example config, after loading all documents found in exampledocs in the index (just to show that it seems to work - of course you need a larger corpus to make it interesting): http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst I haven't tested this extensively yet, will do in the next few days. But comments are welcome of course. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-118) Some admin pages stop working with error 404 as the only symptom
Some admin pages stop working with error 404 as the only symptom -- Key: SOLR-118 URL: https://issues.apache.org/jira/browse/SOLR-118 Project: Solr Issue Type: Bug Components: web gui Environment: Fedora Core 4 (Linux version 2.6.11-1.1369_FC4smp) Sun's JVM 1.5.0_07-b03 Reporter: Bertrand Delacretaz Priority: Minor This was reported to the mailing list a while ago, see http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200610.mbox/[EMAIL PROTECTED] Today I'm seeing the same thing on a Solr instance that has been running since January 9th (about 13 days) with the plain start.jar setup. Index contains 150'000 docs, 88322 search requests to date. $ curl http://localhost:8983/solr/admin/analysis.jsp html head titleError 404 /admin/analysis.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/analysis.jsp/pre pRequestURI=/solr/admin/analysis.jsp/p ... curl http://localhost:8983/solr/admin/index.jsp html head titleError 404 /admin/index.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/index.jsp/pre pRequestURI=/solr/admin/index.jsp/p ... Other admin pages work correctly, for example http://localhost:8983/solr/admin/stats.jsp I don't see any messages in the logs, which are capturing stdout and stderr from the JVM. I guess I'll have to restart this instance, I'm out of possibilities to find out what's happening exactly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-118) Some admin pages stop working with error 404 as the only symptom
[ https://issues.apache.org/jira/browse/SOLR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466468 ] Bertrand Delacretaz commented on SOLR-118: -- Yes, this is the Jetty that is bundled with Solr, Jetty/5.1.11RC0 according to the Server HTTP header. I haven't investigated on the Jetty side yet, it might be a known bug there Some admin pages stop working with error 404 as the only symptom -- Key: SOLR-118 URL: https://issues.apache.org/jira/browse/SOLR-118 Project: Solr Issue Type: Bug Components: web gui Environment: Fedora Core 4 (Linux version 2.6.11-1.1369_FC4smp) Sun's JVM 1.5.0_07-b03 Reporter: Bertrand Delacretaz Priority: Minor This was reported to the mailing list a while ago, see http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200610.mbox/[EMAIL PROTECTED] Today I'm seeing the same thing on a Solr instance that has been running since January 9th (about 13 days) with the plain start.jar setup. Index contains 150'000 docs, 88322 search requests to date. $ curl http://localhost:8983/solr/admin/analysis.jsp html head titleError 404 /admin/analysis.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/analysis.jsp/pre pRequestURI=/solr/admin/analysis.jsp/p ... curl http://localhost:8983/solr/admin/index.jsp html head titleError 404 /admin/index.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/index.jsp/pre pRequestURI=/solr/admin/index.jsp/p ... Other admin pages work correctly, for example http://localhost:8983/solr/admin/stats.jsp I don't see any messages in the logs, which are capturing stdout and stderr from the JVM. I guess I'll have to restart this instance, I'm out of possibilities to find out what's happening exactly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-118) Some admin pages stop working with error 404 as the only symptom
[ https://issues.apache.org/jira/browse/SOLR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466496 ] Bertrand Delacretaz commented on SOLR-118: -- Upgrading is probably a good idea, at least to a released 5.x version, as apparently we're using a release candidate. Some admin pages stop working with error 404 as the only symptom -- Key: SOLR-118 URL: https://issues.apache.org/jira/browse/SOLR-118 Project: Solr Issue Type: Bug Components: web gui Environment: Fedora Core 4 (Linux version 2.6.11-1.1369_FC4smp) Sun's JVM 1.5.0_07-b03 Reporter: Bertrand Delacretaz Priority: Minor This was reported to the mailing list a while ago, see http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200610.mbox/[EMAIL PROTECTED] Today I'm seeing the same thing on a Solr instance that has been running since January 9th (about 13 days) with the plain start.jar setup. Index contains 150'000 docs, 88322 search requests to date. $ curl http://localhost:8983/solr/admin/analysis.jsp html head titleError 404 /admin/analysis.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/analysis.jsp/pre pRequestURI=/solr/admin/analysis.jsp/p ... curl http://localhost:8983/solr/admin/index.jsp html head titleError 404 /admin/index.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/index.jsp/pre pRequestURI=/solr/admin/index.jsp/p ... Other admin pages work correctly, for example http://localhost:8983/solr/admin/stats.jsp I don't see any messages in the logs, which are capturing stdout and stderr from the JVM. I guess I'll have to restart this instance, I'm out of possibilities to find out what's happening exactly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-118) Some admin pages stop working with error 404 as the only symptom
[ https://issues.apache.org/jira/browse/SOLR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466539 ] Bertrand Delacretaz commented on SOLR-118: -- I suspect that it was a JSP issue with Jetty. Yes, certainly. Nothing seems to indicate a problem in Solr's code. Some admin pages stop working with error 404 as the only symptom -- Key: SOLR-118 URL: https://issues.apache.org/jira/browse/SOLR-118 Project: Solr Issue Type: Bug Components: web gui Environment: Fedora Core 4 (Linux version 2.6.11-1.1369_FC4smp) Sun's JVM 1.5.0_07-b03 Reporter: Bertrand Delacretaz Priority: Minor This was reported to the mailing list a while ago, see http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200610.mbox/[EMAIL PROTECTED] Today I'm seeing the same thing on a Solr instance that has been running since January 9th (about 13 days) with the plain start.jar setup. Index contains 150'000 docs, 88322 search requests to date. $ curl http://localhost:8983/solr/admin/analysis.jsp html head titleError 404 /admin/analysis.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/analysis.jsp/pre pRequestURI=/solr/admin/analysis.jsp/p ... curl http://localhost:8983/solr/admin/index.jsp html head titleError 404 /admin/index.jsp/title /head body h2HTTP ERROR: 404/h2pre/admin/index.jsp/pre pRequestURI=/solr/admin/index.jsp/p ... Other admin pages work correctly, for example http://localhost:8983/solr/admin/stats.jsp I don't see any messages in the logs, which are capturing stdout and stderr from the JVM. I guess I'll have to restart this instance, I'm out of possibilities to find out what's happening exactly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465092 ] Bertrand Delacretaz commented on SOLR-69: - SOLR-69.patch updated PATCH:MoreLikeThis support -- Key: SOLR-69 URL: https://issues.apache.org/jira/browse/SOLR-69 Project: Solr Issue Type: Improvement Components: search Reporter: Bertrand Delacretaz Priority: Minor Attachments: lucene-queries-2.0.0.jar, SOLR-69.patch, SOLR-69.patch Here's a patch that implements simple support of Lucene's MoreLikeThis class. The MoreLikeThisHelper code is heavily based on (hmm...lifted from might be more appropriate ;-) Erik Hatcher's example mentioned in http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html To use it, add at least the following parameters to a standard or dismax query: mlt=true mlt.fl=list,of,fields,which,define,similarity See the MoreLikeThisHelper source code for more parameters. Here are two URLs that work with the example config, after loading all documents found in exampledocs in the index (just to show that it seems to work - of course you need a larger corpus to make it interesting): http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst I haven't tested this extensively yet, will do in the next few days. But comments are welcome of course. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-110) Factor out common code in our SolrRequestHandler classes
Factor out common code in our SolrRequestHandler classes Key: SOLR-110 URL: https://issues.apache.org/jira/browse/SOLR-110 Project: Solr Issue Type: Improvement Components: search Reporter: Bertrand Delacretaz DisMaxRequestHandler and StandardRequestHandler are similar enough to warrant a common base class, or helper classes to factor out common code. I don't have the time (or courage ;-) to do that right now, but it should be done to save time when implementing features that impact both classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465114 ] Bertrand Delacretaz commented on SOLR-69: - The method used to compute includeScore in MoreLikeThisHelper was inconsistent with what the XmlWriter does. I have changed it to take this info from SolrQueryResponse.getReturnFields(). The md5 sum of the current SOLR-69 patch is b6178d11d33f19b296b741a67df00d45 With this change, all the following requests should work (standard and dismax handlers, with no fl param, id only and id + score as return fields): http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mintf=1 http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mintf=1fl=id http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mintf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mintf=1 http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mintf=1fl=id http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mintf=1fl=id,score PATCH:MoreLikeThis support -- Key: SOLR-69 URL: https://issues.apache.org/jira/browse/SOLR-69 Project: Solr Issue Type: Improvement Components: search Reporter: Bertrand Delacretaz Priority: Minor Attachments: lucene-queries-2.0.0.jar, SOLR-69.patch, SOLR-69.patch, SOLR-69.patch Here's a patch that implements simple support of Lucene's MoreLikeThis class. The MoreLikeThisHelper code is heavily based on (hmm...lifted from might be more appropriate ;-) Erik Hatcher's example mentioned in http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html To use it, add at least the following parameters to a standard or dismax query: mlt=true mlt.fl=list,of,fields,which,define,similarity See the MoreLikeThisHelper source code for more parameters. Here are two URLs that work with the example config, after loading all documents found in exampledocs in the index (just to show that it seems to work - of course you need a larger corpus to make it interesting): http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst I haven't tested this extensively yet, will do in the next few days. But comments are welcome of course. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[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_12464709 ] Bertrand Delacretaz commented on SOLR-86: - I like the idea of a very simple update only client. It's probably simple enough to create two versions, one using HttpClient and one with no dependencies apart from the JDK? I agree with Hoss that the post.sh replacement should use the latter. IMHO it's good to show the use of HttpClient for people who're going to base more complex clients on it, and a no depedencies client is useful for simple cases. Maybe (thinking outloud here) both clients could implement a common SolrUpdateClientInterface, and update+search clients would implement a SolrSearchInterface as well. [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 Attachments: 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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-20) A simple Java client with Java APIs for add(), delete(), commit() and optimize().
[ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-20: Component/s: (was: update) clients - java A simple Java client with Java APIs for add(), delete(), commit() and optimize(). - Key: SOLR-20 URL: https://issues.apache.org/jira/browse/SOLR-20 Project: Solr Issue Type: New Feature Components: clients - java Environment: all Reporter: Darren Erik Vengroff Priority: Minor Attachments: DocumentManagerClient.java, DocumentManagerClient.java, solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar, solr-client.zip, solr-client.zip, SolrClientException.java, SolrServerException.java I wrote a simple little client class that can connect to a Solr server and issue add, delete, commit and optimize commands using Java methods. I'm posting here for review and comments as suggested by Yonik. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-30) Java client code for performing searches against a Solr instance
[ https://issues.apache.org/jira/browse/SOLR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-30: Component/s: (was: search) clients - java Java client code for performing searches against a Solr instance Key: SOLR-30 URL: https://issues.apache.org/jira/browse/SOLR-30 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Philip Jacob Priority: Minor Attachments: solrsearcher-client.zip Here are a few classes that connect to a Solr instance to perform searches. Results are returned in a Response object. The Response encapsulates a ListMapString,Field that gives you access to the key data in the results. This is the main part that I'm looking for comments on. There are 2 dependencies for this code: JDOM and Commons HttpClient. I'll remove the JDOM dependency in favor of regular DOM at some point, but I think that the HttpClient dependency is worthwhile here. There's a lot that can be exploited with HttpClient that isn't demonstrated in this class. The purpose here is mainly to get feedback on the API of SolrSearcher before I start optimizing anything. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-51) SolrQuery - PHP query client for Solr
[ https://issues.apache.org/jira/browse/SOLR-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-51: Summary: SolrQuery - PHP query client for Solr (was: SolrQuery) SolrQuery - PHP query client for Solr - Key: SOLR-51 URL: https://issues.apache.org/jira/browse/SOLR-51 Project: Solr Issue Type: New Feature Environment: PHP, ADODB, curl Reporter: Brian Lucas Attachments: SolrQuery.php PHP client for querying a SOLR datastore -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-50) SolrUpdate - PHP update client for Solr
[ https://issues.apache.org/jira/browse/SOLR-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SOLR-50: Summary: SolrUpdate - PHP update client for Solr (was: SolrUpdate) SolrUpdate - PHP update client for Solr --- Key: SOLR-50 URL: https://issues.apache.org/jira/browse/SOLR-50 Project: Solr Issue Type: New Feature Components: update Environment: PHP, ADODB, Curl Reporter: Brian Lucas Attachments: SolrUpdate.php This provides the PHP client for adding information to Solr. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-90) Typo in java docs of QueryParsing.java
[ http://issues.apache.org/jira/browse/SOLR-90?page=all ] Bertrand Delacretaz resolved SOLR-90. - Resolution: Fixed Fixed, thanks! This issue wins the Shortest Lived Patch In Solr History Award ;-) Typo in java docs of QueryParsing.java --- Key: SOLR-90 URL: http://issues.apache.org/jira/browse/SOLR-90 Project: Solr Issue Type: Improvement Reporter: Thorsten Scherler Index: /home/thorsten/src/apache/solr/src/java/org/apache/solr/search/QueryParsing.java === --- /home/thorsten/src/apache/solr/src/java/org/apache/solr/search/QueryParsing.java (revision 489078) +++ /home/thorsten/src/apache/solr/src/java/org/apache/solr/search/QueryParsing.java (working copy) @@ -408,7 +408,7 @@ * The benefit of using this method instead of calling * codeQuery.toString/code directly is that it knows about the data * types of each field, so any field which is encoded in a particularly - * complex way is still readable. The downside is thta it only knows + * complex way is still readable. The downside is that it only knows * about built in Query types, and will not be able to format custom * Query classes. * /p -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-59) Copy request parameters to Solr's response
[ http://issues.apache.org/jira/browse/SOLR-59?page=all ] Bertrand Delacretaz resolved SOLR-59. - Resolution: Fixed Let's try my brand new Jira karma by resolving this... Copy request parameters to Solr's response -- Key: SOLR-59 URL: http://issues.apache.org/jira/browse/SOLR-59 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Attachments: SOLR-59-20061024.patch, SOLR-59-20061102.patch, SOLR-59-20061103.patch, SOLR-59-20061106-newfiles.tar.gz, SOLR-59-20061106.patch, SOLR-59-20061213.patch, SOLR-59-new-files-20061102.tar.gz This patch copies the request parameters (explicit ones only, not the defaults) to Solr's XML output. It is not configurable yet, it is enabled by default and adds a queryParameters list to the responseHeader: responseHeader status0/status QTime1/QTime lst name=queryParameters arr name=multi strred/str strblue/str /arr str name=rows10/str str name=start0/str str name=indenton/str str name=qsolr/str str name=stylesheet/ str name=version2.1/str /lst /responseHeader The above example includes a multi-valued parameter, multi. This might still change a bit, but if someone wants to play with it or improve it, here you go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-84) New Solr logo?
[ http://issues.apache.org/jira/browse/SOLR-84?page=all ] Bertrand Delacretaz updated SOLR-84: Attachment: solr-84-source-files.zip solr-84-source-files.zip contains Adobe Illustrator and SVG versions of the proposed logo. New Solr logo? -- Key: SOLR-84 URL: http://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: solr-84-source-files.zip, solr-logo-20061214.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-84) New Solr logo?
[ http://issues.apache.org/jira/browse/SOLR-84?page=all ] Bertrand Delacretaz updated SOLR-84: Attachment: solr-logo-20061214.jpg New Solr logo? -- Key: SOLR-84 URL: http://issues.apache.org/jira/browse/SOLR-84 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Priority: Minor Attachments: solr-logo-20061214.jpg Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) sarraux-dessous.ch) has reworked his logo proposal to be more solar. This can either be the start of a logo contest, or if people like it we could adopt it. The gradients can make it a bit hard to integrate, not sure if this is really a problem. WDYT? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-76) New look for the HTML admin pages
[ http://issues.apache.org/jira/browse/SOLR-76?page=comments#action_12458432 ] Bertrand Delacretaz commented on SOLR-76: - The more sunny design is solr-green-sunny.jpg (why doesn't Jira keep the connection between attachments and their comments?) New look for the HTML admin pages - Key: SOLR-76 URL: http://issues.apache.org/jira/browse/SOLR-76 Project: Solr Issue Type: Improvement Components: web gui Reporter: Bertrand Delacretaz Priority: Minor Attachments: solr-beige.jpg, solr-black.jpg, solr-green-sunny.jpg, solr-green.jpg As discussed on the mailing list (http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200611.mbox/[EMAIL PROTECTED]), I'm going to attach the suggested designs here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-59) Copy request parameters to Solr's response
[ http://issues.apache.org/jira/browse/SOLR-59?page=comments#action_12458466 ] Bertrand Delacretaz commented on SOLR-59: - Thanks Yonik, I have commited your patch. I have renamed the OutputWriterTest.testOriginalSolrWriter test to testSOLR59responseHeaderVersions, and added a test where the versionparameter is not used. I think you can close this issue (apparently I don't have sufficient permissions to do that). Copy request parameters to Solr's response -- Key: SOLR-59 URL: http://issues.apache.org/jira/browse/SOLR-59 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Attachments: SOLR-59-20061024.patch, SOLR-59-20061102.patch, SOLR-59-20061103.patch, SOLR-59-20061106-newfiles.tar.gz, SOLR-59-20061106.patch, SOLR-59-20061213.patch, SOLR-59-new-files-20061102.tar.gz This patch copies the request parameters (explicit ones only, not the defaults) to Solr's XML output. It is not configurable yet, it is enabled by default and adds a queryParameters list to the responseHeader: responseHeader status0/status QTime1/QTime lst name=queryParameters arr name=multi strred/str strblue/str /arr str name=rows10/str str name=start0/str str name=indenton/str str name=qsolr/str str name=stylesheet/ str name=version2.1/str /lst /responseHeader The above example includes a multi-valued parameter, multi. This might still change a bit, but if someone wants to play with it or improve it, here you go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-75) XSLT-based Schema Browser in admin view
[ http://issues.apache.org/jira/browse/SOLR-75?page=comments#action_12456316 ] Bertrand Delacretaz commented on SOLR-75: - The tango icons (http://tango.freedesktop.org) could be used I think. As mentioned at the bottom of http://tango.freedesktop.org/Tango_Desktop_Project, they are licensed under the Creative Commons Attribution Share-Alike license, which I think is acceptable for us to redistribute (although there is no black/white policy on this yet at the ASF, see [1] and [2]). [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200610.mbox/[EMAIL PROTECTED] [2] http://www.apache.org/legal/3party.html XSLT-based Schema Browser in admin view - Key: SOLR-75 URL: http://issues.apache.org/jira/browse/SOLR-75 Project: Solr Issue Type: New Feature Components: web gui Environment: any Reporter: Greg Ludington Priority: Minor Attachments: closed.gif, open.gif, solr75v1.diff The files in this upcoming patch create a simple schema browser for the admin tool. It serves schema.xml along with a stylesheet that in compliant browsers creates a page with a tree widget to show the fieldtypes and fields, as well as their uses and cross references. This is similar to the schemaxsl.zip originally attached to SOLR-58, but a few features have been added, and the look and feel has been changed to fit in better with the rest of the admin tool. Note that it does *not* work against the live IndexSchema -- it merely transforms schema.xml. There is probably not a significant difference now, but it is worth raising the issue in case there are future administration capabilities in mind (i.e. on http://wiki.apache.org/solr/MakeSolrMoreSelfService ) that might require a schema browser to be talking to the live values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-76) New look for the HTML admin pages
[ http://issues.apache.org/jira/browse/SOLR-76?page=comments#action_12456322 ] Bertrand Delacretaz commented on SOLR-76: - I agree that it'd be good to have a closer connection to the sun. Nicolas says the hard part is in avoiding the cheap holiday club look ;-) Maybe solar flares would help make a clear connection while staying subtle, I like the power that such images evoke: http://hesperia.gsfc.nasa.gov/sftheory/fulldisk.htm http://perso.orange.fr/universimmedia/soleil/lexique/protuberances.htm I told Nicolas to think about it, but if others have ideas, let's see them! New look for the HTML admin pages - Key: SOLR-76 URL: http://issues.apache.org/jira/browse/SOLR-76 Project: Solr Issue Type: Improvement Components: web gui Reporter: Bertrand Delacretaz Priority: Minor Attachments: solr-beige.jpg, solr-black.jpg, solr-green.jpg As discussed on the mailing list (http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200611.mbox/[EMAIL PROTECTED]), I'm going to attach the suggested designs here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-76) New look for the HTML admin pages
[ http://issues.apache.org/jira/browse/SOLR-76?page=comments#action_12454851 ] Bertrand Delacretaz commented on SOLR-76: - Got Nicolas' email wrong: nicolas (put at here) sarraux-dessous.ch New look for the HTML admin pages - Key: SOLR-76 URL: http://issues.apache.org/jira/browse/SOLR-76 Project: Solr Issue Type: Improvement Components: web gui Reporter: Bertrand Delacretaz Priority: Minor Attachments: solr-beige.jpg, solr-black.jpg, solr-green.jpg As discussed on the mailing list (http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200611.mbox/[EMAIL PROTECTED]), I'm going to attach the suggested designs here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-3) create test harness and port TestApp to junit
[ http://issues.apache.org/jira/browse/SOLR-3?page=comments#action_12454257 ] Bertrand Delacretaz commented on SOLR-3: No objection here, keeping the code clean is a Good Thing create test harness and port TestApp to junit - Key: SOLR-3 URL: http://issues.apache.org/jira/browse/SOLR-3 Project: Solr Issue Type: Task Reporter: Hoss Man Assigned To: Hoss Man Priority: Minor Attachments: SOLR-3.zip, TestBasicFunctionality.java, TestHarness.java To both encourage good internal development, and to make it easy for plugin developers to write unit tests of their own code I think we need a harness that makes it easy to unit test updates and queries against Solr (without needing a servlet container) Once we have this, i think we can/should also retire TestApp in favor of some JUnit tests (which would probably make more sense for other developers) Iv'e already started on this, i thought i'd have something to commit tonight, but i got distracted ... filing this bug as a tracker for now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-71) New support for Date Math when adding/quering date fields
[ http://issues.apache.org/jira/browse/SOLR-71?page=comments#action_12450981 ] Bertrand Delacretaz commented on SOLR-71: - This looks like a very useful feature! New support for Date Math when adding/quering date fields --- Key: SOLR-71 URL: http://issues.apache.org/jira/browse/SOLR-71 Project: Solr Issue Type: New Feature Components: search, update Reporter: Hoss Man Assigned To: Hoss Man Attachments: DateMath.patch New utility class and changes to DateField to support syntax like the following... startDate:[* TO NOW] startDate:[* TO NOW/DAY+1DAY] expirationDate:[NOW/DAY TO *] reviewDate:[NOW/DAY-1YEAR TO NOW/DAY] validDate:[NOW/MONTH TO NOW/MONTH+1MONTH-1MILLISECOND] ...where + and - mean what you think, and /UNIT rounds down to the nearest UNIT. The motivation for this being that date range queries like these are usefull for filters, but being date sensitve can't currently be baked in to a config as default params. a nice side effect of the implimentation, is that timestamp fields can be done with a document is added by using... field name=myTimestampFieldNOW/field ...and Solr will compute the value when adding the document ... if we add default values to the schema.xml even that won't be neccessary. Comments? (I'd be particularly gratefull if smarter people then I would sanity check my use of ThreadLocal for managing the DateFormat in DateField ... i've never used ThreadLocal before. Any general comments on the syntax would also be appreciated: This left-to-right syntax seemed more intuative to write (and easier to parse) then some of the other syntaxes I'd considered) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-69) PATCH:MoreLikeThis support
[ http://issues.apache.org/jira/browse/SOLR-69?page=all ] Bertrand Delacretaz updated SOLR-69: Attachment: SOLR-69.patch PATCH:MoreLikeThis support -- Key: SOLR-69 URL: http://issues.apache.org/jira/browse/SOLR-69 Project: Solr Issue Type: Improvement Components: search Reporter: Bertrand Delacretaz Priority: Minor Attachments: SOLR-69.patch Here's a patch that implements simple support of Lucene's MoreLikeThis class. The MoreLikeThisHelper code is heavily based on (hmm...lifted from might be more appropriate ;-) Erik Hatcher's example mentioned in http://www.mail-archive.com/solr-user@lucene.apache.org/msg00878.html To use it, add at least the following parameters to a standard or dismax query: mlt=true mlt.fl=list,of,fields,which,define,similarity See the MoreLikeThisHelper source code for more parameters. Here are two URLs that work with the example config, after loading all documents found in exampledocs in the index (just to show that it seems to work - of course you need a larger corpus to make it interesting): http://localhost:8983/solr/select/?stylesheet=q=apacheqt=standardmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score http://localhost:8983/solr/select/?stylesheet=q=apacheqt=dismaxmlt=truemlt.fl=manu,catmlt.mindf=1mlt.mindf=1fl=id,score Results are added to the output like this: response ... lst name=moreLikeThis result name=UTF8TEST numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idSOLR1000/str /doc /result result name=SOLR1000 numFound=1 start=0 maxScore=1.5293242 doc float name=score1.5293242/float str name=idUTF8TEST/str /doc /result /lst I haven't tested this extensively yet, will do in the next few days. But comments are welcome of course. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-59) Copy request parameters to Solr's response
[ http://issues.apache.org/jira/browse/SOLR-59?page=comments#action_12447713 ] Bertrand Delacretaz commented on SOLR-59: - Ah ok, as the JSON format hasn't changed, I guess it just needs recreating this in the XMLWriter: responseHeader status0/status QTime1234/QTime /responseHeader When version 2.2 I probably won't have time to do that today or tomorrow, but of course feel free to patch my patch if you want. Copy request parameters to Solr's response -- Key: SOLR-59 URL: http://issues.apache.org/jira/browse/SOLR-59 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Attachments: SOLR-59-20061024.patch, SOLR-59-20061102.patch, SOLR-59-20061103.patch, SOLR-59-20061106-newfiles.tar.gz, SOLR-59-20061106.patch, SOLR-59-new-files-20061102.tar.gz This patch copies the request parameters (explicit ones only, not the defaults) to Solr's XML output. It is not configurable yet, it is enabled by default and adds a queryParameters list to the responseHeader: responseHeader status0/status QTime1/QTime lst name=queryParameters arr name=multi strred/str strblue/str /arr str name=rows10/str str name=start0/str str name=indenton/str str name=qsolr/str str name=stylesheet/ str name=version2.1/str /lst /responseHeader The above example includes a multi-valued parameter, multi. This might still change a bit, but if someone wants to play with it or improve it, here you go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-59) Copy request parameters to Solr's response
[ http://issues.apache.org/jira/browse/SOLR-59?page=all ] Bertrand Delacretaz updated SOLR-59: Attachment: SOLR-59-20061106-newfiles.tar.gz Copy request parameters to Solr's response -- Key: SOLR-59 URL: http://issues.apache.org/jira/browse/SOLR-59 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Attachments: SOLR-59-20061024.patch, SOLR-59-20061102.patch, SOLR-59-20061103.patch, SOLR-59-20061106-newfiles.tar.gz, SOLR-59-20061106.patch, SOLR-59-new-files-20061102.tar.gz This patch copies the request parameters (explicit ones only, not the defaults) to Solr's XML output. It is not configurable yet, it is enabled by default and adds a queryParameters list to the responseHeader: responseHeader status0/status QTime1/QTime lst name=queryParameters arr name=multi strred/str strblue/str /arr str name=rows10/str str name=start0/str str name=indenton/str str name=qsolr/str str name=stylesheet/ str name=version2.1/str /lst /responseHeader The above example includes a multi-valued parameter, multi. This might still change a bit, but if someone wants to play with it or improve it, here you go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-59) Copy request parameters to Solr's response
[ http://issues.apache.org/jira/browse/SOLR-59?page=all ] Bertrand Delacretaz updated SOLR-59: Attachment: SOLR-59-20061103.patch ...I think it might make more sense to use the normal query parameter mechanism to control this (requestHandler defaults in solrconfig). .. I agree, but I'm not sure how to access these values, are they provided somewhere in SolrCore, or how should I best get them? ...Also, why the extra addInfo element in the responseHeader?.. Right, makes no sense. This modifed patch goes back to the previous format (still needs the additional files of attachment 3). responseHeader status0/status QTime1/QTime lst name=explicitQueryParameters str name=rows10/str ... ...should we make responseHeader consistent with the generic response format? I think so. I didn't want to change that as it changes the existing format, but it makes sense. Copy request parameters to Solr's response -- Key: SOLR-59 URL: http://issues.apache.org/jira/browse/SOLR-59 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Attachments: SOLR-59-20061024.patch, SOLR-59-20061102.patch, SOLR-59-20061103.patch, SOLR-59-new-files-20061102.tar.gz This patch copies the request parameters (explicit ones only, not the defaults) to Solr's XML output. It is not configurable yet, it is enabled by default and adds a queryParameters list to the responseHeader: responseHeader status0/status QTime1/QTime lst name=queryParameters arr name=multi strred/str strblue/str /arr str name=rows10/str str name=start0/str str name=indenton/str str name=qsolr/str str name=stylesheet/ str name=version2.1/str /lst /responseHeader The above example includes a multi-valued parameter, multi. This might still change a bit, but if someone wants to play with it or improve it, here you go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-59) Copy request parameters to Solr's response
Copy request parameters to Solr's response -- Key: SOLR-59 URL: http://issues.apache.org/jira/browse/SOLR-59 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz This patch copies the request parameters (explicit ones only, not the defaults) to Solr's XML output. It is not configurable yet, it is enabled by default and adds a queryParameters list to the responseHeader: responseHeader status0/status QTime1/QTime lst name=queryParameters arr name=multi strred/str strblue/str /arr str name=rows10/str str name=start0/str str name=indenton/str str name=qsolr/str str name=stylesheet/ str name=version2.1/str /lst /responseHeader The above example includes a multi-valued parameter, multi. This might still change a bit, but if someone wants to play with it or improve it, here you go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-59) Copy request parameters to Solr's response
[ http://issues.apache.org/jira/browse/SOLR-59?page=all ] Bertrand Delacretaz updated SOLR-59: Attachment: SOLR-59-20061024.patch Copy request parameters to Solr's response -- Key: SOLR-59 URL: http://issues.apache.org/jira/browse/SOLR-59 Project: Solr Issue Type: Improvement Reporter: Bertrand Delacretaz Attachments: SOLR-59-20061024.patch This patch copies the request parameters (explicit ones only, not the defaults) to Solr's XML output. It is not configurable yet, it is enabled by default and adds a queryParameters list to the responseHeader: responseHeader status0/status QTime1/QTime lst name=queryParameters arr name=multi strred/str strblue/str /arr str name=rows10/str str name=start0/str str name=indenton/str str name=qsolr/str str name=stylesheet/ str name=version2.1/str /lst /responseHeader The above example includes a multi-valued parameter, multi. This might still change a bit, but if someone wants to play with it or improve it, here you go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-58) Change Admin components to return XML like the rest of the system
[ http://issues.apache.org/jira/browse/SOLR-58?page=comments#action_12444015 ] Bertrand Delacretaz commented on SOLR-58: - Once the admin components emit XML, The XSLT transformation code written for SOLR-49 could be used to recreate an HTML user interface easily. Change Admin components to return XML like the rest of the system - Key: SOLR-58 URL: http://issues.apache.org/jira/browse/SOLR-58 Project: Solr Issue Type: New Feature Components: web gui Reporter: Otis Gospodnetic Assigned To: Otis Gospodnetic Priority: Minor I need to expose the admin functionality to an external application. I think returning admin data as XML may be a good and simple first step towards that. To do that I think I'll mostly need to modify JSPs (but I haven't had a good look at Admin GUI yet). From what I saw a few weeks ago when I briefly looked at this, no Java code will need to be modified. If you have concrete ideas about how this should be done, please comment before I start next week (week of October 23rd 2006). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-49) PATCH: XSLTServletFilter
[ http://issues.apache.org/jira/browse/SOLR-49?page=comments#action_12443761 ] Bertrand Delacretaz commented on SOLR-49: - Thanks for committing, I have documented this at http://wiki.apache.org/solr/XsltResponseWriter PATCH: XSLTServletFilter Key: SOLR-49 URL: http://issues.apache.org/jira/browse/SOLR-49 Project: Solr Issue Type: New Feature Components: search Environment: Tested on macosx 10.4.7, JDK 1.5.0_06 Reporter: Bertrand Delacretaz Assigned To: Hoss Man Priority: Minor Attachments: SOLR-49.diff, solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz Patch that implements server-side XSLT transforms of query results. The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example: http://localhost:8983/solr/select/html?q=usagetransform=my.xsl In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format. Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far. The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already. The patch is all new files, except for adding this in web.xml before the first servlet: filter filter-namexslt/filter-name filter-classorg.apache.solr.xslt.XSLTServletFilter/filter-class /filter !-- apply the XSLT filter when select/html is used to make queries -- filter-mapping filter-namexslt/filter-name url-pattern/select/html/*/url-pattern /filter-mapping I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ] Bertrand Delacretaz updated SOLR-49: Attachment: solr-XSLTResponseWriter-20061016.tar.gz Here's the latest incarnation, using a more Solrish way of initializing the response writer. The solr-XSLTResponseWriter-20061016.tar.gz attachment replaces all the previous patches. I have added an init(NamedList args) method to the QueryResponseWriter (solr-49.patch in the attached file), which means that the solrconfig.xml part has changed: !-- XSLT response writer (SOLR-49) Changes to XSLT transforms are taken into account every xsltCacheLifetimeSeconds at most. -- queryResponseWriter name=xslt class=org.apache.solr.request.XSLTResponseWriter int name=xsltCacheLifetimeSeconds5/int /queryResponseWriter Apart from that, the patch works as indicated in my previous comment. PATCH: XSLTServletFilter Key: SOLR-49 URL: http://issues.apache.org/jira/browse/SOLR-49 Project: Solr Issue Type: New Feature Components: search Environment: Tested on macosx 10.4.7, JDK 1.5.0_06 Reporter: Bertrand Delacretaz Priority: Minor Attachments: solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-20061016.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz Patch that implements server-side XSLT transforms of query results. The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example: http://localhost:8983/solr/select/html?q=usagetransform=my.xsl In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format. Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far. The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already. The patch is all new files, except for adding this in web.xml before the first servlet: filter filter-namexslt/filter-name filter-classorg.apache.solr.xslt.XSLTServletFilter/filter-class /filter !-- apply the XSLT filter when select/html is used to make queries -- filter-mapping filter-namexslt/filter-name url-pattern/select/html/*/url-pattern /filter-mapping I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ] Bertrand Delacretaz updated SOLR-49: Attachment: solr-XSLTResponseWriter-20060922.tar.gz Here's yet another version which takes the Content-Type from the XSLT transform. The code and these instructions replace the previous versions: Must be configured like this in solrconfig.xml: !-- XSLT response writer (SOLR-49) Changes to XSLT transforms are taken into account every xsltCacheLifetimeSeconds at most. -- queryResponseWriter name=xslt class=org.apache.solr.request.XSLTResponseWriter xsltCacheLifetimeSeconds=5 / The following request parameters activate the XSLTResponseWriter: wt = xslt tr = my-xslt-transform.xsl The Content-Type comes from the xsl:output element of the XSLT transform: xsl:output media-type=text/html/ And finally, the TransformerProvider warns about the possible performance implications of its simplistic cache, when first used: ATTENTION: The TransformerProvider's simplistic XSLT caching mechanism is not appropriate for high load scenarios, unless a single XSLT transform is used and xsltCacheLifetimeSeconds is set to a sufficiently high value. PATCH: XSLTServletFilter Key: SOLR-49 URL: http://issues.apache.org/jira/browse/SOLR-49 Project: Solr Issue Type: New Feature Components: search Environment: Tested on macosx 10.4.7, JDK 1.5.0_06 Reporter: Bertrand Delacretaz Priority: Minor Attachments: solr-XSLTResponseWriter-20060922.tar.gz, solr-XSLTResponseWriter-files.tar.gz, xslt-filter-files.tar.gz Patch that implements server-side XSLT transforms of query results. The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example: http://localhost:8983/solr/select/html?q=usagetransform=my.xsl In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format. Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far. The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already. The patch is all new files, except for adding this in web.xml before the first servlet: filter filter-namexslt/filter-name filter-classorg.apache.solr.xslt.XSLTServletFilter/filter-class /filter !-- apply the XSLT filter when select/html is used to make queries -- filter-mapping filter-namexslt/filter-name url-pattern/select/html/*/url-pattern /filter-mapping I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-49) PATCH: XSLTServletFilter
PATCH: XSLTServletFilter Key: SOLR-49 URL: http://issues.apache.org/jira/browse/SOLR-49 Project: Solr Issue Type: New Feature Components: search Environment: Tested on macosx 10.4.7, JDK 1.5.0_06 Reporter: Bertrand Delacretaz Priority: Minor Patch that implements server-side XSLT transforms of query results. The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example: http://localhost:8983/solr/select/html?q=usagetransform=my.xsl In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format. Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far. The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already. The patch is all new files, except for adding this in web.xml before the first servlet: filter filter-namexslt/filter-name filter-classorg.apache.solr.xslt.XSLTServletFilter/filter-class /filter !-- apply the XSLT filter when select/html is used to make queries -- filter-mapping filter-namexslt/filter-name url-pattern/select/html/*/url-pattern /filter-mapping I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-49) PATCH: XSLTServletFilter
[ http://issues.apache.org/jira/browse/SOLR-49?page=all ] Bertrand Delacretaz updated SOLR-49: Attachment: xslt-filter-files.tar.gz New files PATCH: XSLTServletFilter Key: SOLR-49 URL: http://issues.apache.org/jira/browse/SOLR-49 Project: Solr Issue Type: New Feature Components: search Environment: Tested on macosx 10.4.7, JDK 1.5.0_06 Reporter: Bertrand Delacretaz Priority: Minor Attachments: xslt-filter-files.tar.gz Patch that implements server-side XSLT transforms of query results. The filter is activated by using select/html instead of select/ to run queries, and optionally adding a transform parameter to specify the XSLT transform to use, for example: http://localhost:8983/solr/select/html?q=usagetransform=my.xsl In which case my.xsl should be found in solr/conf/xslt/ with the example configuration. The default transform (solr/conf/xslt/query-to-html.xsl) outputs a simplistic HTML format. Performance is suboptimal, as the filter reparses the XML output generated by Solr. Modifying the XMLWriter to output to a ContentHandler would be more efficient, but I didn't have time to go that far. The TransformerProvider trivially caches the last Transformer used, could be improved using an LRU cache of several transformers, I haven't checked if Solr's infrastructure contains such an animal already. The patch is all new files, except for adding this in web.xml before the first servlet: filter filter-namexslt/filter-name filter-classorg.apache.solr.xslt.XSLTServletFilter/filter-class /filter !-- apply the XSLT filter when select/html is used to make queries -- filter-mapping filter-namexslt/filter-name url-pattern/select/html/*/url-pattern /filter-mapping I've left the client-side XSLT stuff (stylesheet parameter) as is for the moment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-33) PATCH: TestXMLEscaping contribution
[ http://issues.apache.org/jira/browse/SOLR-33?page=all ] Bertrand Delacretaz updated SOLR-33: Attachment: TestXMLEscaping.java Tests that XML escaping works properly with strings containing non-ASCII characters. PATCH: TestXMLEscaping contribution --- Key: SOLR-33 URL: http://issues.apache.org/jira/browse/SOLR-33 Project: Solr Issue Type: Test Reporter: Bertrand Delacretaz Priority: Minor Attachments: TestXMLEscaping.java Attachment contains an additional unit test, created to diagnose SOLR-32: does a few simple character escaping tests for the util/XML class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-27) PATCH: Configurable language for SnowballPorterFilterFactory
[ http://issues.apache.org/jira/browse/SOLR-27?page=all ] Bertrand Delacretaz updated SOLR-27: Attachment: SnowballPorterFilterFactory.patch The single souce file to patch PATCH: Configurable language for SnowballPorterFilterFactory Key: SOLR-27 URL: http://issues.apache.org/jira/browse/SOLR-27 Project: Solr Type: Improvement Components: search Reporter: Bertrand Delacretaz Priority: Minor Attachments: SnowballPorterFilterFactory.patch With this patch, the language used by SnowballPorterFilterFactory is configurable, for example: filter class=solr.SnowballPorterFilterFactory language=French/ Invalid languages will cause a ClassNotFoundException when the filter is created (so at search time possibly, not at initialization time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
