Re: Marking myself inactive (was: svn commit: r662366...)
On Thu, Jun 5, 2008 at 1:53 AM, Chris Hostetter [EMAIL PROTECTED] wrote: ...I look forward to the day when you get bored with all the stuff you are doing now, and start catching up on all your Solr mail :)... Thanks for the kind words - noted ;-) -Bertrand
Marking myself inactive (was: svn commit: r662366...)
Hi Solr people, On Mon, Jun 2, 2008 at 10:56 AM, [EMAIL PROTECTED] wrote: Author: bdelacretaz Date: Mon Jun 2 01:56:41 2008 New Revision: 662366... As you can see I have marked myself inactive on the http://lucene.apache.org/solr/who.html page (should be updated in a few hours) - it's been almost a year since I did anything for Solr, and with 1504 unread messages in my Solr inbox folder, it's about time ;-) It's been a pleasure working with you guys, and meeting some of you at conferences. I'll be around, but my work has changed a lot since last year, and I don't use Solr in my current projects. The few projects that I did during my short involvement with Solr are still running strong, keep up the good work! -Bertrand
Re: Solr production live implementation
On 11/2/07, Tim Archambault [EMAIL PROTECTED] wrote: ...I am currently trying SOLR out off of my dedicated Windows server (IIS 5) with Jetty. My server has 2GB Ram and tons of space. What is the likelyhood that this environment is good enough for my production environment?... FWIW, http://tsrvideo.ch/ (a video browser backed by a Solr index) runs on a mid-range 2006 Intel server (don't have the exact setup here, probably a dual Xeon 2GHz, 4GB RAM), with Linux + Apache httpd, and is coping very well with about 1.5 million Solr queries a month on average. BTW, I just had a look and the Solr instance there has been up since July 11th, not bad! I'd suggest estimating your peak load and running stress tests with something like ab (the httpd utility), JMeter or httpstone [1] to find out what happens to your index under peak load. You might use your current bandwidth stats to estimate how big your peaks are compared to the average load. -Bertrand [1] http://code.google.com/p/httpstone/source (some assembly required, that's a very simple java-based HTTP stress-test framework that I wrote)
[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.
Re: removing most @author tags
On 7/10/07, Yonik Seeley [EMAIL PROTECTED] wrote: ...Should we remove all author tags for solr code, or only for those who voted +1?... I'd say all author tags, and just in case here's my belated +1 to the proposal that started this thread. -Bertrand
[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.
Re: [VOTE] release rc2 as Solr 1.2
On 5/31/07, Yonik Seeley [EMAIL PROTECTED] wrote: ...Please vote to release these artifacts as Apache Solr 1.2... +1 -Bertrand
Re: [VOTE] release Solr 1.2
On 5/30/07, Yonik Seeley [EMAIL PROTECTED] wrote: ...I propose to release the artifacts at http://people.apache.org/~yonik/staging_area/solr/1.2/ as Apache Solr 1.2... +1 I haven't followed the latest developments, but all JUnit tests pass, example setup works (macosx/JDK1.5), and signatures and md5 look good (checked the tgz file only). -Bertrand
Re: [Solr Wiki] Update of HowToContribute by BertrandDelacretaz
On 4/30/07, Chris Hostetter [EMAIL PROTECTED] wrote: ...eh? ... the https port is open to everyone as well correct?.. Yes you're right, sorry about that. I have corrected http://wiki.apache.org/solr/HowToContribute, but left http instead of https in the svn co example. I think we usually advertise http over https for read-only access, as it causes less load on our servers, and possibly less firewall problems. -Bertrand
Re: svn commit: r533596 - /lucene/solr/trunk/src/java/org/apache/solr/handler/admin/PropertiesRequestHandler.java
On 4/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ...Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/admin/PropertiesRequestHandler.java ... + public static NamedListString toNamedList( Properties p ) IIUC this method is of general use, it might be good to move it to a utility class, org.apache.solr.util.NamedListUtils maybe? -Bertrand
Re: Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
On 4/27/07, Yonik Seeley [EMAIL PROTECTED] wrote: snip-lotsa-good-stuff/ ...My *personal* philosophy is probably more permissive than most:.. Thanks for sharing this, you're totally right that a half-baked patch is better than no patch at all, and that there are different stages which make sense in contributions. Hard rules wouldn't work, but I'm glad we've had this discussion (and I'll go back to my corner now ;-) Also, thanks Hoss for creating http://wiki.apache.org/solr/CommitPolicy, I think it's really good to have this. -Bertrand
Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
(see http://www.apache.org/foundation/glossary.html for what RTC means, if needed) On 4/26/07, Otis Gospodnetic [EMAIL PROTECTED] wrote: ...C'mon, just svn ci everything! Just kidding... Kidding aside, could we check that we agree on the following rules about committing code? I think it's especially important now that Ryan is a committer (and don't get me wrong, I'm *very* happy about that), with lots of his patches pending in Jira, and several of us (IIUC) having little time to review them all. A clear agreement will help us move forward efficiently, IMHO. Here's my understanding of our current (but largely unwritten IIUC) way of working. 1. Solr usually works in RTC mode: patches are first posted to Jira, then committed once we agree on a particular patch. This does not apply to obvious fixes, typos, etc., of course. 2.. Non-trivial patches require a [VOTE] on the dev list before being committed. What's non-trivial? I'd suggest using our common sense and trusting each other to judge this, for a start. 3. Patches, and especially those adding new functionality, must be accompanied by automated tests and some documentation (usually in the Solr wiki). 4. If needed, we could create svn branches for wild experimental stuff, but we prefer to work with small incremental patches if possible. I hope I'm not wasting our collective time with this - feel free to correct, complete, flame, whatever ;-) -Bertrand
Re: Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
Hi Rajesh, On 4/27/07, rubdabadub [EMAIL PROTECTED] wrote: ...The word here is unwritten. This is where is the problem with loads of apache project. Its the few privileged who decides what is a rule or coding conduct. So unwritten rule is a great way of working so long you are singing the same song... I would agree as a general rule - but in a project where face-to-face communications are the exception, I find it good to have explicit agreements on basic principles - even if they are fairly loose. I have tried to always use the word rules in quotes, the intent is more to have a flexible set of basic principles, they are not really rules - we *do* trust each other here, and svn is here to get things back when needed. About the few privileged: at the ASF, each project's PMC has a lot of leeway when it comes to organizing how they work, and it's a good thing. Note that in our case it's the Lucene PMC who oversees Solr (and I'm not part of it ;-) 1. Solr usually works in RTC mode: patches are first posted to Jira, then committed once we agree on a particular patch. This does not apply to obvious fixes, typos, etc., of course. So usually works? So how do you agree? are there any rules there or is it also unwritten? ... No, but there is a lot of trust between committers, so everyone's allowed to diverge from the rules when it makes sense, and we do our best not to be pedantic about them. Hence the usually: it's based on trust and agreeing on a basic set of (relatively loose) principles. Sorry I have a hard time understanding how things gets to trunk. Cos when you look at Solr Jira seems like 90% of the issues are unassigned where 50% being major and 50% being minor. Obviously there are some community needs for those patches, some are bad some are good nevertheless those who are submitting patch should get a honest reply in a decent time frame... Agreed - if you have some patches that you feel should be committed sooner than later, feel free to ask specific questions about why this hasn't happened yet. OTOH we're all volunteers, so Solr users must be prepared to get their hands dirty, and if needed use trunk code (as opposed to released versions) with the patches that they need applied. ...Your comments here are very general, vague, wide open shots. .. That's on purpose, based on the trust thing, and as I said it's a first shot anyway. I think if there are any commits that Ryan made is not to your liking or patch doesn't have test/docs what not then it can be reverted after all its a subversion and its not a part of a release... Sorry if I wasn't clear, but this is *not* against Ryan's way of working, quite the contrary in fact: the goal is to create an environment where people (like Ryan currently) who're working faster than others can go forward as fast as they need, without being dragged down by others who have less available time/energy/whatever. All this while keeping Solr's great code quality, so a bit of discussion doesn't hurt IMHO. ...I been following the list and Ryan made great patches and he has the drive/time and blessings from the PMC so why stop the good thing and his enthusiasm Again, sorry if my message came across as a stop, it's not the intention! ...Just some comments from the sideline.. Thanks: this is not only about committers, as usual all community members are welcome to express themselves. Hope this helps...it'd be so much more efficient to have such discussions f2f over a beer than in writing ;-) -Bertrand
Re: Call for Papers Opens for ApacheCon US 2007
On 4/23/07, Chris Hostetter [EMAIL PROTECTED] wrote: ...I was thinking about submitting two talks... Novice: Solr Out of the Box Advanced: Solr Beyond the Box... Sounds good, and looking at Solr from these two angles certainly makes sense! -Bertrand
Re: Update with fancy characters in xml
On 4/20/07, David Xiao [EMAIL PROTECTED] wrote: I am updating text into solr, use post.sh. I found that if the .xml contains fancy words such as it will actually corrupt xml schema layout. As the document to be posted is XML, it must be well-formed, so you must escape some characters ( and ) in it, according to http://www.w3.org/TR/REC-xml/ -Bertrand
[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.
Re: Replication with IP multicast/broadcast?
On 4/4/07, HUYLEBROECK Jeremy RD-ILAB-SSF [EMAIL PROTECTED] wrote: ...Has anybody thought about using IP multicast to replicate the master to the slaves and then avoid multiple rsync. The replication could happen right away as soon as a add/delete/update happens on the master If you need that, I'd rather go for something like a JMS bus to replicate indexing operations, instead of reinventing something similar. But making it transactional would be hard IMHO, and if it's not transactional the benefits compared to frequent rsyncs are not that big (again IMHO, it depends on your application of course). -Bertrand
Re: solr release planning for 1.2
On 4/3/07, Yonik Seeley [EMAIL PROTECTED] wrote: ...So what features / issues do people think we need to resolve before we make a 1.2 release?... I agree that having a non-incubator release would be good, and as long as it's stable I don't care too much about exactly what new features are in it (also because I have little time for helping ATM). -Bertrand
[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.
[ApacheCon] Early Bird registration ends Tuesday March 27th
Hi everybody, Please note that the Early Bird registration for the ApacheCon Europe 2007 (May 1-4, Amsterdam) ends soon, see below for the official announcement. See http://www.eu.apachecon.com/ for more details and for the program. Hope to see you there! -Bertrand --- Early Bird Registration for ApacheCon Europe 2007 Ends Tuesday 27 March World-Recognized Technologists, Vendors, Thought-Leaders, and Users Convene in Amsterdam to Experience the Future of Open Source Development FOREST HILL, MD -- (MARKET WIRE) -- March 21, 2007 -- ApacheCon Europe 2007, the official conference, trainings, and expo of the Apache Software Foundation (ASF), today announced the deadline for Early Bird registration ends on Tuesday, 27 March 2007. With engaging plenary and keynote addresses, technical presentations, informal networking, peer discussions, Birds-of-a-Feather sessions, and entertaining social events, ApacheCon delves into the highly lauded community that develops and shepherds industry-leading Open Source projects, including Apache HTTP Server -- the world's most popular Web server software for more than a decade. ApacheCon Europe takes place 1-4 May 2007 at the Mövenpick Hotel in Amsterdam, The Netherlands. Special Registration-Plus-Hotel Conference Package offers savings up to US$238; Conference passes range from US$450 - US$1,700 with an average savings of US$150 with Early Bird pricing. Trainings are US$350 for half-day sessions, and US$550 for full-day courses. Register today at http://www.eu.apachecon.com/. With more than 100 sessions on groundbreaking technologies and emerging industry trends, conference participants meet, mingle, and exchange ideas with like-minded peers in a relaxed, community-focused environment. Highlights include: Abstraction and extraction: in praise of: Keynote addresses from Steven Pemberton, Web Usability Expert at CWI and Chair, W3C XHTML and XForms Working Groups. Open Source: It's a license, not a business model or a development model: Keynote address by Dr. Margo Seltzer, Herchel Smith Professor of Computer Science, Harvard University Division of Applied Sciences. Full-and Half-Day Training Sessions taught by industry experts, offering hands-on instruction on Apache Projects Axis2, ApacheDS, Jackrabbit, Jetspeed, HTTP Server, Lucene, Maven, MyFaces, emerging initiatives from the Apache Incubator, and widely-deployed standards such as SSL and XSLT. Popular Developer Presentations on flagship Apache and Open Source technologies, including Geronimo, Harmony, HTTP Server, Tomcat, AJAX, Cocoon, Databases, Derby, Eclipse, Jakarta, LDAP, Portlets, Roller, Security, SpamAssassin, and WebDAV, as well as a look into projects from the ASF Incubator and Labs at the new ApacheCon Fast Feather Track. Business Track featuring panel sessions, presentations, and case studies that address core Open Source business, marketing, standardization, community-building, and legal/licensing issues, as well as explore broader areas such as the Semantic Web, Web Services, Web 2.0, and mobile technologies. Sponsor Events and Expo gives attendees direct access to industry-leading organizations such as BlackHat, Covalent, Google (NASDAQ: GOOG), the Java Community Process, and Sun Microsystems (NASDAQ: SUNW) as well as first-looks at new technologies and products showcased by emerging players such as Hippo, Nexaweb, Ordina, and WSO2. Special Events include geeking, hacking, and relaxing in the Online Lounge, conference and sponsor receptions, out-of-the-box public speaking at the Lighting Talks, and more! Corporate Sponsorship, Exhibitor, and government participation opportunities are available; contact Delia Frees at [EMAIL PROTECTED] or on +1 707 765 0823 for more information. Event media partners include: Apress, CMS Channel, CMS Center, DevTownStation, DigiMedia, European Web Association, Free Software Magazine, Integration Developer News, Linux Magazine, LXer, Methods Tools, Open Enterprise Trends, Slashdot, Software Development Articles Directory, Software Development Tools Directory, Software Development News, and Webtech 2007. To become a Media Partner, contact Sally Khudairi on +1 617 921 8656 or [EMAIL PROTECTED]
[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.
Fwd: Google Summer of Code
FYI - as I said before, I'm unable to mentor a project this year, unfortunately. -- Forwarded message -- From: Ross Gardler [EMAIL PROTECTED] Date: Mar 14, 2007 2:53 PM Subject: Google Summer of Code To: [EMAIL PROTECTED], [EMAIL PROTECTED] Google are due to announce the accepted organisations in the Google Summer of Code today. Unfortunately, I've been really busy with other things recently and have not managed to organise the ASF application as well as I might. However, I did manage to notify the [EMAIL PROTECTED] list of the process and I did get an application in on time. So, now to the next stage. This message is mailed to members@ as well as [EMAIL PROTECTED] Please feel free to distribute to your projects, I chose not to send to community@ or committers@ because I'm aware different projects like to manage GSoC applications in different ways. It's up to the members to take this forward in individual projects. Student applications will open today and will close on March 24th. If your projects want to accept applications from GSoC students then you need to ensure you have details listed on http://wiki.apache.org/general/SummerOfCode2007 If you want more info on what being a mentor means then a good place to start is http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors Interested parties should also subscribe to [EMAIL PROTECTED] where all internal communication about GSoC occurs (like how we select which projects to accept). Ross
[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.
Re: post.jar
Hi, On 2/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ...I have just started using the solr server in the tutorial they have given an example which uses post.jar but i dont find the post.jar in the solr download and i find only the post.sh... The tutorial on the website reflects the current development state, but the post.jar code is not yet included in a released version of Solr. In the meantime, you can download a version of post.jar from http://tinyurl.com/2bnm4a (or compile it yourself from the current trunk code, if you prefer). -Bertrand
[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.
Re: [Solr Wiki] Update of FrontPage by HossMan
On 2/17/07, Apache Wiki [EMAIL PROTECTED] wrote: ...The following page has been changed by HossMan: http://wiki.apache.org/solr/FrontPage.. FYI, I have asked infrastructure@ about using the http://moinmoin.wikiwikiweb.de/AntiSpamGlobalSolution to prevent wiki spam. -Bertrand
[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.
Re: commit requests
On 2/12/07, Erik Hatcher [EMAIL PROTECTED] wrote: ... * SOLR-79: to allow launching a common schema/config with various data directories... +1 ... * A newer version of Lucene's JAR: to have *:* syntax... +0, don't know enough about the issues to comment. -Bertrand
tsr.ch goes live with Solr!
Hi Solr community, I've been talking about my current project for months, it's finally live at http://www.tsr.ch/tsr/index.html?siteSect=50 It's the new video player page of our national (French-speaking part of Switzerland) TV network, backed by a Solr index fed by a continuous stream of incoming videos, as soon as editors enter them in their existing CMS. It's all in French but I've added some info in English at http://codeconsult.ch/bertrand/archives/000760.html. I'm going to base my ApacheCon talk on this example, to show how well Solr copes with mixed queries, combining structured, database-like searches with full-text. Solr is mostly used to generate all the dynamic navigation features of that page (via Ajaxish calls), the search function is there but the exploration features are much more prominent. I like it very much: don't search, find. Hope you like it...it's all Ajax and video player plugins (they haven't converted their large collection of videos to Flash yet), so you might find some bugs. If so, I'd love to hear about them off-list. Big thanks to the Lucene and Solr folks for making this possible, my part (creating the index back-end and assisting the front-end developers) has been very easy to implement thanks to these great tools! -Bertrand
Re: excommunicating Ruby
On 2/9/07, Erik Hatcher [EMAIL PROTECTED] wrote: ...We've had ruby-dev@lucene.apache.org for a while now, but it is a ghost town. Let's revive it and use that list for sol.rb and Flare discussions from now on... +1, good idea! - Bertrand, trying hard to keep up with Solr java stuff already ;-)
[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
Re: continuous integration for solrb
On 1/22/07, Erik Hatcher [EMAIL PROTECTED] wrote: ...I don't know much about our Solaris zone, so could someone fill me in on it a bit?... I haven't seen Solr's zone yet, but basically zones are Solaris (virtual) machines where some of us can get root access, so we can install anything there as long as it plays nice with other zones in terms of CPU and memory usage. Currently all of the ASF's zones are sharing a - fairly powerful - physical machine. For example, the Cocoon zone at http://cocoon.zones.apache.org/ runs live demos of Cocoon pulled automatically out of SVN every few hours by crontab scripts, the Continuum continuous integration server, and the Daisy CMS for editing docs. There's more info at http://www.apache.org/dev/solaris-zones.html HTH, -Bertrand
Re: Update Plugins (was Re: Handling disparate data sources in Solr)
On 1/16/07, Ryan McKinley [EMAIL PROTECTED] wrote: ...I think a DocumentParser registry is a good way to isolate this top level task... With all this talk about plugins, registries etc., /me can't help thinking that this would be a good time to introduce the Spring IoC container to manage this stuff. More info at http://www.springframework.org/docs/reference/beans.html for people who are not familiar with it. It's very easy to use for simple cases like the ones we're talking about. -Bertrand
[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
Re: query to pull all document ids in an index
On 1/16/07, Edward Summers [EMAIL PROTECTED] wrote: I was thinking I could do a query that pulls back all the document ids in the index, and then delete each one... The delete by query feature will do this without requiring an iteration on the client side, see http://incubator.apache.org/solr/tutorial.html#Deleting+Data -Bertrand
Re: SOLR-67 query interface
On 1/16/07, rlawson [EMAIL PROTECTED] wrote: ...I'm new to SOLR and would like to contribute. I think my skills would best lend themselves to helping with a nice query interface. I'm a java web dev by profession... If you mean graphic design of the admin webpages, there are two issues about this currently: http://issues.apache.org/jira/browse/SOLR-84 http://issues.apache.org/jira/browse/SOLR-76 Your opinions and contributions are of course welcome! ...www.kemperinvestors.com (don't blame me, client wanted it that way)... ouch ;-) -Bertrand
To Spring or not to Spring? (was: Update Plugins)
On 1/16/07, Alan Burlison [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: .../me can't help thinking that this would be a good time to introduce the Spring IoC container to manage this stuff... Please, no. I work on a big webapp that uses spring - it's a complete nightmare to figure out what's going on. Using just the IoC container? I'm not talking about full-blown Spring magic, *just* IoC to assemble plugins. Spring's IoC is not complicated, and logging statements and debuggers are here to find out exactly what's happening if needed. I don't think it'd be more complicated than using our homegrown plugin system. Only more tested, documented and well-known. -Bertrand
Re: To Spring or not to Spring? (was: Update Plugins)
On 1/16/07, Alan Burlison [EMAIL PROTECTED] wrote: ...I've had *bad* experiences with apps where people pulled in just about every framework, component and widget you can think of... That's what you previous message seemed to imply ;-) I agree that, if we start using Spring (or another) IoC container, we must be careful to use what actually helps us, and not let it become our Code Dictator... -Bertrand
Re: Java version for solr development (was Re: Update Plugins)
On 1/17/07, Thorsten Scherler [EMAIL PROTECTED] wrote: ...Should I use 1.6 for a patch or above mentioned libs?... IMHO moving to 1.6 is way too soon, and if it's only to save two jars it's not worth it. -Bertrand
[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
Re: Update Plugins (was Re: Handling disparate data sources in Solr)
On 1/16/07, Chris Hostetter [EMAIL PROTECTED] wrote:
interface SolrRequestParser {
SolrRequest process( HttpServletRequest req );
}
(the trick being that the servlet would need to parse the st info out
of the URL (either from the path or from the QueryString) directly without
using any of the HttpServletRequest.getParameter*() methods...
I haven't followed all of the discussion, but wouldn't it be easier to
use the request path, instead of parameters, to select these
RequestParsers?
i.e. solr/update/pdf-parser, solr/update/hssf-parser,
solr/update/my-custom-parser, etc.
-Bertrand
Re: SQL UpdatePlugin?
On 1/12/07, Ryan McKinley [EMAIL PROTECTED] wrote: ...What is the best way to post unfinished code and ask for review? Should i make a JIRA issue and post a patch with a not ready for prime time note? ... Yes, this would work. Our personal NotReadyForPrimeTime detectors would flag it immediately anyway, if needed ;-) Putting TODO comments in your code in places where you feel others should have a look can help if you're unsure about how to best implement certain things. -Bertrand
Re: Giving credit to sponsors?
On 1/12/07, Otis Gospodnetic [EMAIL PROTECTED] wrote: ...Are there existing practices for giving credit to companies that sponsor development of Solr.. I don't think we have something like that yet. Cocoon 2.1.x has a CREDITS.txt file for listing such contributions: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/CREDITS.txt I'm thinking of the Community Credits part a the top, the rest is covered by our NOTICE.txt file. Putting this stuff besides the LICENCE.txt and NOTICE.txt files makes sense IMHO, as this is similar to licence and software credits info. The website could say look at the CREDITS.txt file with a link to the SVN version like above. -Bertrand
Re: adding modes to the add command
On 1/11/07, Ryan McKinley [EMAIL PROTECTED] wrote: How do you all feel about adding various modes to the add command? Something like: mode=add or replace document (default, the current behavior) mode=add or replace fields mode=add fields mode=add distinct fields... Although this is useful as you explain, I like the current simplicity of the Solr HTTP/XML interface very much. The more options we add, the harder it becomes to understand and test the interface. So, IMHO, it would be good for this functionality to be provided in a plugin, disabled by default. IIUC the modifications the the Solr core are minimal, these can included in the core, but (again IMHO, this is debatable for sure) the public interface to this should be provided by a special plugin. -Bertrand
[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
Re: Is Solr ready for graduation?
On 1/3/07, Yoav Shapira [EMAIL PROTECTED] wrote: ...I'd say definitely ask Lucene first. (And in general ask the accepting TLP first, before asking the Incubator). +1 from me to starting the discussion, and +1 for graduating Same opinion on all points here. -Bertrand
Re: Is Solr ready for graduation?
On 1/4/07, Yonik Seeley [EMAIL PROTECTED] wrote: ...This thread looks like it's the first vote (unless anyone objects), so here's my +1 for graduation... I hate to be formal, but I'd much prefer voting to happen in clearly identified [VOTE] threads. As the community grows, or when people get busy, this helps in not missing these all-important threads. -Bertrand
Re: [VOTE] graduate Solr to Lucene subproject
[X ] +1 ask Lucene PMC and the Incubator PMC to graduate Solr from the Incubator to become a Lucene subproject. -Bertrand
Re: ApacheCon Europe '07 Solr proposals?
On 12/25/06, Chris Hostetter [EMAIL PROTECTED] wrote: ...if you and Erik are both submitting proposals, I'm a happy camper... Ok, so I like the double-decker idea, let's wait for Erik's reply about that. I'd gladly talk about my current project: concrete examples of how to prepare and inject existing content into Solr, and show an interesting video player based on a solr metadata backend, using the HTTP/JSON interface. Or, if Erik wants to talk about more advanced stuff, I could do the intro talk. I'll be mostly offline in the next few days, I'll actually work on the proposal after January 2nd (CFP deadline is Jan.12th). -Bertrand
Re: ApacheCon Europe '07 Solr proposals?
On 11/30/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...Oh, and people should feel free to pilfer anything that might be useful my last presentation Is anyone submitting an intro to Solr talk? I'm planing to submit a case study of my current project (how to graft Solr on existing CMSes, preparing documents, ajax frontends, etc.), but I think we should have an introductory talk as well. -Bertrand
Re: Which schema.xml to modify for a patch?
On 12/22/06, Yonik Seeley [EMAIL PROTECTED] wrote: The one in example is the recommended starting point for users... I have added this info as comments in the schema files to clarify this. -Bertrand
Re: Solr 1.1 released
On 12/22/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...Solr 1.1 is now available for download!... Yoo-hooh, congratulations, virtual champagne everybody! -Bertrand
[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
Re: Bertrand's Jira perms
On 12/18/06, Erik Hatcher [EMAIL PROTECTED] wrote: I've added bdelacretaz to the solr-developers group in JIRA... Thanks, Ithe additional Jira functions work for me now. -Bertrand
Re: [VOTE] release Apache Solr 1.1.0
On 12/16/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...I have posted a candidate release at http://people.apache.org/~yonik/solr/staging_area/... I noticed that none of the scripts (post.sh and the ones in example/solr/bin/) have the executable bit set, although it its set in SVN. Dunno how this works when cutting a release under cygwin, maybe the ant chmod task would help? -Bertrand
Re: [VOTE] release Apache Solr 1.1.0
On 12/17/06, Yonik Seeley [EMAIL PROTECTED] wrote: OK, I did a respin with *only* changes to build.xml to change the executable bits of scripts Thanks! The executable bits are even set when expanding (on macosx) the zip file, didn't expect this to work. I have checked the signatures and md5, here's my +1 for the release. -Bertrand
[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
Re: [jira] Created: (SOLR-84) New Solr logo?
On 12/15/06, Chris Hostetter [EMAIL PROTECTED] wrote: ...hey, we are considering a new logo and want your input... I've asked on solr-user, see Opinions wanted about a new Solr logo (SOLR-58) there. -Bertrand
[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
Re: test release artifacts
On 12/14/06, Yonik Seeley [EMAIL PROTECTED] wrote: Sounds like a plan... issues 58,59,78 left. 59 is done now. -Bertrand
Re: remove dist-src and dist-example ?
On 12/8/06, Chris Hostetter [EMAIL PROTECTED] wrote: ...any objection to removing them to help the build.xml easy to follow?... not here, sounds good. -Bertrand
Re: test release artifacts
On 12/8/06, Chris Hostetter [EMAIL PROTECTED] wrote: ...is that really how most apache projects manage keys? .. import a big existing list from some other project and then gradually grow it? Most I don't know, Cocoon, Forrest and others do it. And the current KEYS.txt is just *my* key (which has some signatures ;-) ...I would have assumed there was some central list of keys for Apache commiters... Dunno if there's one, usually I'd look for keys at pgp.mit.edu or similar servers. The KEYS.txt file is just a convenience for people to easily find keys of the people who sign releases, not really a key management tool. My key is probably not needed there as I'm not going to sign releases, so feel free to remove it, I added it as an example. We could also just have the URLs of people's keys in there. -Bertrand
Re: correct format for the md5 files?
On 12/8/06, Chris Hostetter [EMAIL PROTECTED] wrote: ...but it got me wondering, what format do we want?... The format that Yonik used works (on my macosx system, but also under Linux I suspect) with md5sum -c apache-solr-1.1.0-incubating.tgz.md5 which is convenient I think. -Bertrand
[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
Re: test release artifacts
On 12/8/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...Could you go through the process of trying to verify the signatures?... Signatures for both the .tgz and .zip files pass, after importing your key from pgp.mit.edu into my gpg keystore. I have added http://svn.apache.org/repos/asf/incubator/solr/trunk/KEYS.txt to make it easier for people to get our keys, it would be good to add yours there. -Bertrand Example: gpg --verify apache-solr-1.1.0-incubating.tgz.asc apache-solr-1.1.0-incubating.tgz gpg: Signature made Fri Dec 8 04:22:19 2006 CET using DSA key ID 0AFCEE7C gpg: Good signature from Yonik Seeley [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: E404 B4CF 10D8 F153 04F7 651C B83E A82A 0AFC EE7C
[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
Re: release requirements status
On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: ...I thought this was exactly what the NOTICE file is for? Mention all the code from other projects we use, including ASL code. LICENSE is just for our own (Solr) stuff... Hmmm..you're right (it's Friday here, it's been a long week ;-) -Bertrand
Re: XML config
On 11/29/06, Yonik Seeley [EMAIL PROTECTED] wrote: [subject changed to avoid the auto-add to JIRA feature] On 11/28/06, Walter Underwood (JIRA) [EMAIL PROTECTED] wrote: Requiring users to edit an XML file is a separate issue, but I think it is a serious problem, While many Solr users may not know Java or Lucene, they most likely will have a familiarity with XML (or at least enough HTML that the XML doesn't look foreign) How would one feed documents into Solr without knowing XML? I think this is a non-issue, people have to generate XML documents to index them with Solr anyway, so editing an XML configuration file is not that bad. ...especially because any error messages show up in the server logs... I agree that this is more serious, making critical exceptions or logs accessible from the HTTP interface could be good...but it can also be a security risk in some cases, you don't necessarily want to expose all error messages to the world. IMHO: for any serious use of Solr, people need some server management skills. It might be better for people who don't have these to fail early, rather than wrongly think that they can use Solr in point and click mode. -Bertrand
[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
New look for the HTML admin pages?
Hi Solr team, We have a multimedia designer student working as a trainee in our office, and I could probably grab him for one or two days to improve the looks of the Solr admin pages (needs probably only a new CSS stylesheet and a few background images). I don't know who designed these pages, and maybe they have some sentimental value, but IMHO they could look better - while remaining simple and clean of course. How does that sound? If there's agreement, I'll ask him to come up with 2-3 proposals that we can vote on. -Bertrand
Re: New look for the HTML admin pages?
On 11/29/06, Zaheed Haque [EMAIL PROTECTED] wrote: ...--- you come to nice admin interface --- then you perform a search from the admin tool. -- and you get a XSLT/XML based results and it has similler look like the admin tool... Ok, got it now! Good idea, there could be an option on the search page to see results in HTML with the same looks as the admin pages. -Bertrand
Re: Phonetic Token Filter
On 11/21/06, Walter Underwood [EMAIL PROTECTED] wrote: ...It is worth a try. Most implementations of Double Metaphone are well-commented, so you could change it for other languages... Ok, I'll see if I find some time to test that, thanks for the clarifications! -Bertrand
