[jira] [Created] (SOLR-3874) add time to live for documents
jiangwen wei created SOLR-3874: -- Summary: add time to live for documents Key: SOLR-3874 URL: https://issues.apache.org/jira/browse/SOLR-3874 Project: Solr Issue Type: New Feature Components: update Reporter: jiangwen wei allow user to set the time to live of documents, and solr automatically delete the documents that are not live! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_07) - Build # 904 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/904/ Java: 64bit/jdk1.7.0_07 -XX:+UseG1GC All tests passed Build Log: [...truncated 25455 lines...] BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\build.xml:241: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:549: Unable to delete file C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\build\analysis\common\lucene-analyzers-common-5.0-SNAPSHOT.jar Total time: 53 minutes 43 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseG1GC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3874) add time to live for documents
[ https://issues.apache.org/jira/browse/SOLR-3874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461746#comment-13461746 ] Erick Erickson commented on SOLR-3874: -- My first reaction is that this kind of functionality doesn't belong in Solr since Solr is really an engine. It seems simple enough for the application to include a delete_on date when indexing and your app to periodically issue a delete-by query something like delete_on:[* to NOW] add time to live for documents -- Key: SOLR-3874 URL: https://issues.apache.org/jira/browse/SOLR-3874 Project: Solr Issue Type: New Feature Components: update Reporter: jiangwen wei allow user to set the time to live of documents, and solr automatically delete the documents that are not live! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3840) XML query response display is unreadable in Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461753#comment-13461753 ] Stefan Matheis (steffkes) commented on SOLR-3840: - Jepp, that's right .. depends a bit on your Browser, if it will render the XML correctly .. or not :/ At the Beginning we thought about using the same (clientside) XML-Renderer like we have in place for displaying the schema.xml/solrconfig.xml, but if we do so the browser features to expand/collapse the xml-tree (or whatever your browser has implemented) are gone. And right know, i don't have a chance to detect if the client is able to render xml as xml or not. what we could think about, is offering a second view: one nativ, the second rendered ... so the user could decide which one to use? XML query response display is unreadable in Solr Admin Query UI --- Key: SOLR-3840 URL: https://issues.apache.org/jira/browse/SOLR-3840 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Environment: Google Chrome, Windows 7 - Firefox as well Reporter: Jack Krupansky Attachments: Query-UI-XML-unreadable.png If I execute a query in the Solr Admin Query UI, the default XML writer displays only the raw text of the Solr response XML element values, but none of the XML syntax itself, rendering the response display on the Query page almost completely useless. JSON, Ruby, et al display very reasonably formatted output, but XML does not. You can click on the icon next to the generated query URL to display the response in a browser tab of its own and then it does display the XML very reasonably, but the framed display on the query page is simply not readable. My recollection is that the old UI had this same problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3412) ShowFileRequestHandler shouldn't log SEVERE error and stack trace if file not found
[ https://issues.apache.org/jira/browse/SOLR-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-3412. - Resolution: Fixed That should be solved with [r1386773|http://svn.apache.org/viewvc?view=revisionrevision=1386773] on SOLR-3759 ShowFileRequestHandler shouldn't log SEVERE error and stack trace if file not found --- Key: SOLR-3412 URL: https://issues.apache.org/jira/browse/SOLR-3412 Project: Solr Issue Type: Improvement Affects Versions: 4.0-ALPHA Reporter: David Smiley Priority: Trivial Original Estimate: 20m Remaining Estimate: 20m When I bring up the new Admin UI for the example-DIH solr home, I noticed these obnoxious supposedly SEVERE errors in my Solr log: SEVERE: org.apache.solr.common.SolrException: Can not find: admin-extra.menu-top.html [/SmileyDev/Search/lucene-solr_trunk/solr/example/example-DIH/solr/db/conf/admin-extra.menu-top.html] at org.apache.solr.handler.admin.ShowFileRequestHandler.showFromFileSystem(ShowFileRequestHandler.java:229) ... I think this is a warning at most, and it certainly doesn't need the stack trace. Perhaps it would be useful to have a parameter to indicate the client will deal with it not being found and thus log at info? I dunno -- perhaps that's over-engineering it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
+1, smoke tester is happy on Ubuntu 12.04. Mike McCandless http://blog.mikemccandless.com On Mon, Sep 24, 2012 at 12:11 AM, Robert Muir rcm...@gmail.com wrote: Artifacts are here: http://s.apache.org/lusolr40rc0 Thanks, Robert -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4421) TermsFilter should use TermsEnum.seekExact not seekCeil
David Smiley created LUCENE-4421:
Summary: TermsFilter should use TermsEnum.seekExact not seekCeil
Key: LUCENE-4421
URL: https://issues.apache.org/jira/browse/LUCENE-4421
Project: Lucene - Core
Issue Type: Improvement
Components: core/search
Reporter: David Smiley
Priority: Minor
TermsFilter line 82 is:
if (termsEnum.seekCeil(br) == TermsEnum.SeekStatus.FOUND) {
I expected use of seekExact(...) since the Filter shouldn't need to
potentially advance to the one after.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1389334 - in /lucene/dev/trunk: ./ dev-tools/ dev-tools/scripts/smokeTestRelease.py
On Mon, Sep 24, 2012 at 8:31 AM, mikemcc...@apache.org wrote:
import tarfile
import threading
+import traceback
import subprocess
import signal
...
@@ -112,7 +113,14 @@ def getHREFs(urlString):
break
links = []
- for subUrl, text in
reHREF.findall(urllib.request.urlopen(urlString).read().decode('UTF-8')):
+ try:
+html = urllib.request.urlopen(urlString).read().decode('UTF-8')
+ except:
+print('\nFAILED to open url %s' % urlString)
+tracekback.print_exc()
+raise
This is a tpyo right? you meant traceback not tracekback ?
--
lucidworks.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
Toke Eskildsen created SOLR-3875:
Summary: Document boost does not work correctly when using
multi-valued fields
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA, 4.0, 4.1, 5.0
Reporter: Toke Eskildsen
Fix For: 4.0, 4.1, 5.0, 4.0-BETA
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15 values
in a multi value field results in scores above 1,000,000,000, while a boost of
0,5 results in scores below 0,001. The error is not present in Solr 3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example mentioned
above, the generated IndexableFields will get assigned boosts of 5, 5*5, 5*5...
5*5. As Lucene multiplies all the values, 15 instances of the same field will
have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the sample
documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for _thomas_
matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the moment,
but we guess that a reversion to the old algorithm of assigning the combined
boost to the first instance and 1.0f to all subsequent instances would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1389362 - /lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/package.html
Whats the problem? everything works fine here (ant documentation-lint) with 1.6.0_26: BUILD SUCCESSFUL Total time: 2 minutes 20 seconds rmuir@beast:~/workspace/lucene-trunk/lucene$ $JAVA_HOME/bin/java -version java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) On Mon, Sep 24, 2012 at 9:36 AM, jpou...@apache.org wrote: Author: jpountz Date: Mon Sep 24 13:36:50 2012 New Revision: 1389362 URL: http://svn.apache.org/viewvc?rev=1389362view=rev Log: Fix javadocs generation with javadoc 1.6.0_26 (and maybe other versions?). Modified: lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/package.html Modified: lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/package.html URL: http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/package.html?rev=1389362r1=1389361r2=1389362view=diff == --- lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/package.html (original) +++ lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/package.html Mon Sep 24 13:36:50 2012 @@ -21,6 +21,7 @@ /head body Code to maintain and access indices. + !-- TODO: add IndexWriter, IndexWriterConfig, DocValues, etc etc -- h2Table Of Contents/h2 p -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3840) XML query response display is unreadable in Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461794#comment-13461794 ] Jack Krupansky commented on SOLR-3840: -- Just to be clear, both Chrome and Firefox on Windows know how to render XML, and in fact if I click on the icon next to the query URL the XML displays properly when it is a page of its own in the browser. I don't have any browser add-ons - I use the browsers exactly as they are downloaded. Is there maybe some add-on that might be needed? Or maybe some option(s) that need to be enabled or disabled? I would add that when I do display the XML by clicking on the URL icon, Chrome does also inform me that there is no CSS available. It still formats the XML properly though. Somebody must have some clue as to while this specific feature of the Solr UI would behave differently on my system. My current suspicion is that the Solr UI is dependent on some add-on that your average Solr committer happens to have also installed. XML query response display is unreadable in Solr Admin Query UI --- Key: SOLR-3840 URL: https://issues.apache.org/jira/browse/SOLR-3840 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Environment: Google Chrome, Windows 7 - Firefox as well Reporter: Jack Krupansky Attachments: Query-UI-XML-unreadable.png If I execute a query in the Solr Admin Query UI, the default XML writer displays only the raw text of the Solr response XML element values, but none of the XML syntax itself, rendering the response display on the Query page almost completely useless. JSON, Ruby, et al display very reasonably formatted output, but XML does not. You can click on the icon next to the generated query URL to display the response in a browser tab of its own and then it does display the XML very reasonably, but the framed display on the query page is simply not readable. My recollection is that the old UI had this same problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
+1, Smoker tester also ran successfully on my machine (Ubuntu 12.04.1) Martijn On 24 September 2012 14:48, Michael McCandless luc...@mikemccandless.com wrote: +1, smoke tester is happy on Ubuntu 12.04. Mike McCandless http://blog.mikemccandless.com On Mon, Sep 24, 2012 at 12:11 AM, Robert Muir rcm...@gmail.com wrote: Artifacts are here: http://s.apache.org/lusolr40rc0 Thanks, Robert -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re:Re: need best solution for indexing and searching multiple, related database tables
I think you should post to java-u...@lucene.apache.org, or the general@~~ list. yup, few help on this lucene ha. but the multi thing.. some words impressed me, that is: Use the source, Luke At 2012-09-24 05:25:07,Biff Baxter tom.bren...@acmedata.net wrote: So far no responses. I did search the existing posts and found some related topics but nothing as specific as I was looking for. Biff-- View this message in context: http://lucene.472066.n3.nabble.com/need-best-solution-for-indexing-and-searching-multiple-related-database-tables-tp4009676p4009733.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1389362 - /lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/index/package.html
On Mon, Sep 24, 2012 at 3:43 PM, Robert Muir rcm...@gmail.com wrote: Whats the problem? everything works fine here (ant documentation-lint) with 1.6.0_26: The problem is that some class-use HTML files are not valid (they contain lines such as TDCode to maintain and access indices.\n!nbsp;/TD that checkJavadocsLinks.py fails to parse. (Robert just suggested on IRC that this problem is due to the fact that my locale is fr_FR. Indeed, running javadoc with the en_US locale fixes the problem...) -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4422) Don't rely on the computer locale to generate javadocs
Adrien Grand created LUCENE-4422: Summary: Don't rely on the computer locale to generate javadocs Key: LUCENE-4422 URL: https://issues.apache.org/jira/browse/LUCENE-4422 Project: Lucene - Core Issue Type: Bug Components: general/build, general/javadocs Affects Versions: 5.0, 4.0 Environment: locale=fr_FR Reporter: Adrien Grand Assignee: Robert Muir Priority: Blocker Fix For: 4.0 With the fr_FR locale, javadoc 1.6.0_26 fails to generate correct HTML output for the class-use files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re:VOTE: release 4.0
many nonsense in the javadocs with the previous release, which should get clean. as well as a clear package tree, that simplifies the usage and configuration. I think the core of lucene is just about the algorithm of full text search, ha. besides are just for locale and administrating, ha. it is important to use the plugin mechanism. At 2012-09-24 12:11:33,Robert Muir rcm...@gmail.com wrote: Artifacts are here: http://s.apache.org/lusolr40rc0 Thanks, Robert -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3874) add time to live for documents
[
https://issues.apache.org/jira/browse/SOLR-3874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461825#comment-13461825
]
Jan Høydahl commented on SOLR-3874:
---
Could this be implemented as a contrib/plugin instead of core functionality?
Such a plugin would need two components:
* An UpdateRequestProcessor looking for a ttl parameter on update requests,
translating it to a timestamp to be indexed as a date in e.g. field ttl_d
* A background job periodically issuing a delete-query towards the ttl_d field
The first is already easy to make and to wire into your update handlers. I'm
not sure what plugin API would fit best for the background job. Most of our
plugin APIs are event driven. Should we create a generic Job plugin point
that could be wired into solrconfig.xml as
{code:xml}
job name=periodic_deleter class=foo.Deleter
int name=pollinterval6/int
str name=fieldttl_d/str
/job
{code}
add time to live for documents
--
Key: SOLR-3874
URL: https://issues.apache.org/jira/browse/SOLR-3874
Project: Solr
Issue Type: New Feature
Components: update
Reporter: jiangwen wei
allow user to set the time to live of documents, and solr automatically
delete the documents that are not live!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Re:VOTE: release 4.0
Hello秋水, Rather than complaining about the javadocs, perhaps you could help by pointing out specific problems? Or even better, create JIRA issues and provide patches: http://wiki.apache.org/lucene-java/HowToContribute Steve From: 秋水 [mailto:sdrkyj_luc...@163.com] Sent: Monday, September 24, 2012 10:19 AM To: dev@lucene.apache.org Subject: Re:VOTE: release 4.0 many nonsense in the javadocs with the previous release, which should get clean. as well as a clear package tree, that simplifies the usage and configuration. I think the core of lucene is just about the algorithm of full text search, ha. besides are just for locale and administrating, ha. it is important to use the plugin mechanism. At 2012-09-24 12:11:33,Robert Muir rcm...@gmail.commailto:rcm...@gmail.com wrote: Artifacts are here: http://s.apache.org/lusolr40rc0 Thanks, Robert -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.orgmailto:dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.orgmailto:dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
Jack Krupansky created SOLR-3876: Summary: Solr Admin UI is completely dysfunctional on IE 9 Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Attachments: screenshot-1.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3876: - Attachment: screenshot-1.jpg Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.0 Attachments: screenshot-1.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3876: - Fix Version/s: 4.0 Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.0 Attachments: screenshot-1.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4411) Depth requested in a facetRequest is reset when Sampling is in effect
[
https://issues.apache.org/jira/browse/LUCENE-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilad Barkai updated LUCENE-4411:
-
Attachment: LUCENE-4411.patch
Attached a proposed fix + test.
Delegating is impossible as {{FacetRequest}}'s getters are {{final}}. The only
way to 'delegate' the information is using the setters in the wrapping class
(e.g setDepth(original.getDepth()).
This solution does not seem the right one, but other approaches involves
changing much more code and reducing the amount of protection the public API
offers (e.g the user will find it easier to break something).
The patch also introduce (the missing) delegation of the {{SortBy}},
{{SortOrder}}, {{numResultsToLable}} and {{ResultMode}} methods.
Somewhat out of scope of the issue - I tried to figure out why the wrapping and
keeping the ??original?? request is important:
The ??count?? (number of categories to return) is {{final}}, set at
construction. While Sampling is in effect, in order to better the chances of
'hitting' the true top-k results, the notion of oversampling is introduced,
which asks for more than just K (e.g 3 * K results) - so another request should
be made. The 'original' request is saves so the end-result would hold the
original request, and not the over-sampled one (every {{FacetResult}} has its
originating {{FacetRequest}}).
Depth requested in a facetRequest is reset when Sampling is in effect
-
Key: LUCENE-4411
URL: https://issues.apache.org/jira/browse/LUCENE-4411
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 3.6.1, 5.0, 4.0
Reporter: Gilad Barkai
Attachments: LUCENE-4411.patch, OversampleWithDepthTest.java,
OversampleWithDepthTest.java
FacetRequest can be set a Depth parameter, which controls the depth of the
result tree to be returned.
When Sampling is enabled (and actually used) the Depth parameter gets reset
to its default (1).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
On Mon, 2012-09-24 at 06:11 +0200, Robert Muir wrote: Artifacts are here: http://s.apache.org/lusolr40rc0 Sorry to interrupt as a non-voter, but I am afraid that https://issues.apache.org/jira/browse/SOLR-3875 might be a blocker for 4.0. Maybe a veteran could take a quick look? - Toke Eskildsen, State and University Library, Denmark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re:RE: Re:VOTE: release 4.0
ok think about it as you suggest 在 2012-09-24 22:29:34，Steven A Rowe sar...@syr.edu 写道： Hello秋水, Rather than complaining about the javadocs, perhaps you could help by pointing out specific problems? Or even better, create JIRA issues and provide patches: http://wiki.apache.org/lucene-java/HowToContribute Steve From:秋水 [mailto:sdrkyj_luc...@163.com] Sent: Monday, September 24, 2012 10:19 AM To:dev@lucene.apache.org Subject: Re:VOTE: release 4.0 many nonsense in the javadocs with the previous release, which should get clean. as well as a clear package tree, that simplifies the usage and configuration. I think the core of lucene is just about the algorithm of full text search, ha. besides are just for locale and administrating, ha. it is important to use the plugin mechanism. At 2012-09-24 12:11:33,Robert Muir rcm...@gmail.com wrote: Artifacts are here: http://s.apache.org/lusolr40rc0 Thanks, Robert -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4422) Don't rely on the computer locale to generate javadocs
[ https://issues.apache.org/jira/browse/LUCENE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4422: Attachment: LUCENE-4422.patch here is the patch I got Adrien to test on IRC. We should commit this to trunk and 4.x so that we have repeatable builds (not failing for developers in country X but passing for developers in country Y). For 4.0: we have options available, we can commit it and respin, or we can simply mention in the errata that if you are going to generate javadocs, you should set some -D's as a workaround. As far as I can tell this bug has always existed in Lucene's build.xml, its just that we never had checkers that would find it :) Don't rely on the computer locale to generate javadocs -- Key: LUCENE-4422 URL: https://issues.apache.org/jira/browse/LUCENE-4422 Project: Lucene - Core Issue Type: Bug Components: general/build, general/javadocs Affects Versions: 5.0, 4.0 Environment: locale=fr_FR Reporter: Adrien Grand Assignee: Robert Muir Priority: Blocker Fix For: 4.0 Attachments: LUCENE-4422.patch With the fr_FR locale, javadoc 1.6.0_26 fails to generate correct HTML output for the class-use files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3876: - Attachment: screenshot-2.jpg After hitting browser refresh the Admin appearance changes a little, but still no collection1 button. Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.0 Attachments: screenshot-1.jpg, screenshot-2.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3876: - Attachment: screenshot-3.jpg And for reference, here is a screenshot of Admin in Chrome running against the same Solr instance as IE 9. Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.0 Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
Somebody is going to need to make a call on whether support for Solr Admin UI in IE 9 is required for 4.0 release. See SOLR-3876. https://issues.apache.org/jira/browse/SOLR-3876 I marked it only as critical, for now. -- Jack Krupansky -Original Message- From: Robert Muir Sent: Monday, September 24, 2012 12:11 AM To: dev@lucene.apache.org Subject: VOTE: release 4.0 Artifacts are here: http://s.apache.org/lusolr40rc0 Thanks, Robert -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
+1 smoke test is happy. I integrated it in my 4.0 apps and ran tests, everything looks good. thanks robert for all the hard work! On Mon, Sep 24, 2012 at 4:04 PM, Martijn v Groningen martijn.v.gronin...@gmail.com wrote: +1, Smoker tester also ran successfully on my machine (Ubuntu 12.04.1) Martijn On 24 September 2012 14:48, Michael McCandless luc...@mikemccandless.com wrote: +1, smoke tester is happy on Ubuntu 12.04. Mike McCandless http://blog.mikemccandless.com On Mon, Sep 24, 2012 at 12:11 AM, Robert Muir rcm...@gmail.com wrote: Artifacts are here: http://s.apache.org/lusolr40rc0 Thanks, Robert -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
[
https://issues.apache.org/jira/browse/SOLR-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-3875:
--
Priority: Critical (was: Major)
Upgrading to Critical. I seldom use document boosts, but could be a showstopper
for some people upgrading.
If a fix is not included, the release notes should mention it as a known bug
and fix in next release.
Document boost does not work correctly when using multi-valued fields
-
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA, 4.0, 4.1, 5.0
Reporter: Toke Eskildsen
Priority: Critical
Fix For: 4.0-BETA, 4.0, 4.1, 5.0
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15
values in a multi value field results in scores above 1,000,000,000, while a
boost of 0,5 results in scores below 0,001. The error is not present in Solr
3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example
mentioned above, the generated IndexableFields will get assigned boosts of 5,
5*5, 5*5... 5*5. As Lucene multiplies all the values, 15 instances of the
same field will have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the
sample documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for
_thomas_ matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result
of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the
moment, but we guess that a reversion to the old algorithm of assigning the
combined boost to the first instance and 1.0f to all subsequent instances
would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4422) Don't rely on the computer locale to generate javadocs
[ https://issues.apache.org/jira/browse/LUCENE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4422: Priority: Minor (was: Blocker) Removing blocker, because: # I set my locale to fr_FR locally and ran this, the javadocs are perfectly readable even if the checker is unhappy. # 'ant javadocs' succeeds with this configuration and again the javadocs are readable. So fr_FR users can generate javadocs even with this specific jdk and they will be readable etc etc. Again this html issue (likely a jdk bug) does not affect the end-user really, since the files in question are perfectly readable. But we should still commit the patch to trunk/4x to avoid false build failures for developers. Don't rely on the computer locale to generate javadocs -- Key: LUCENE-4422 URL: https://issues.apache.org/jira/browse/LUCENE-4422 Project: Lucene - Core Issue Type: Bug Components: general/build, general/javadocs Affects Versions: 5.0, 4.0 Environment: locale=fr_FR Reporter: Adrien Grand Assignee: Robert Muir Priority: Minor Fix For: 4.0 Attachments: LUCENE-4422.patch With the fr_FR locale, javadoc 1.6.0_26 fails to generate correct HTML output for the class-use files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4422) Don't rely on the computer locale to generate javadocs
[ https://issues.apache.org/jira/browse/LUCENE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461854#comment-13461854 ] Adrien Grand commented on LUCENE-4422: -- bq. Again this html issue (likely a jdk bug) does not affect the end-user really, since the files in question are perfectly readable. But we should still commit the patch to trunk/4x to avoid false build failures for developers. Agreed. +1 for your patch Don't rely on the computer locale to generate javadocs -- Key: LUCENE-4422 URL: https://issues.apache.org/jira/browse/LUCENE-4422 Project: Lucene - Core Issue Type: Bug Components: general/build, general/javadocs Affects Versions: 5.0, 4.0 Environment: locale=fr_FR Reporter: Adrien Grand Assignee: Robert Muir Priority: Minor Fix For: 4.0 Attachments: LUCENE-4422.patch With the fr_FR locale, javadoc 1.6.0_26 fails to generate correct HTML output for the class-use files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1389334 - in /lucene/dev/trunk: ./ dev-tools/ dev-tools/scripts/smokeTestRelease.py
On Mon, Sep 24, 2012 at 9:38 AM, Robert Muir rcm...@gmail.com wrote:
On Mon, Sep 24, 2012 at 8:31 AM, mikemcc...@apache.org wrote:
import tarfile
import threading
+import traceback
import subprocess
import signal
...
@@ -112,7 +113,14 @@ def getHREFs(urlString):
break
links = []
- for subUrl, text in
reHREF.findall(urllib.request.urlopen(urlString).read().decode('UTF-8')):
+ try:
+html = urllib.request.urlopen(urlString).read().decode('UTF-8')
+ except:
+print('\nFAILED to open url %s' % urlString)
+tracekback.print_exc()
+raise
This is a tpyo right? you meant traceback not tracekback ?
Woops yes :) I'll fix. Thanks.
Mike McCandless
http://blog.mikemccandless.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461860#comment-13461860 ] Christian Moen commented on SOLR-3876: -- Thanks a lot for this, Jack. I'm afraid I don't know the overall status nor history of the 4.0 UI in IE9, but do you happen to know if this is a regression of it the UI has been generally broken for IE9 all along? To me it sounds quite important to get this fixed for 4.0 and I can help working some on this. Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.0 Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4422) Don't rely on the computer locale to generate javadocs
[ https://issues.apache.org/jira/browse/LUCENE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461863#comment-13461863 ] Michael McCandless commented on LUCENE-4422: +1 Don't rely on the computer locale to generate javadocs -- Key: LUCENE-4422 URL: https://issues.apache.org/jira/browse/LUCENE-4422 Project: Lucene - Core Issue Type: Bug Components: general/build, general/javadocs Affects Versions: 5.0, 4.0 Environment: locale=fr_FR Reporter: Adrien Grand Assignee: Robert Muir Priority: Minor Fix For: 4.0 Attachments: LUCENE-4422.patch With the fr_FR locale, javadoc 1.6.0_26 fails to generate correct HTML output for the class-use files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4422) Don't rely on the computer locale to generate javadocs
[
https://issues.apache.org/jira/browse/LUCENE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461865#comment-13461865
]
Michael McCandless commented on LUCENE-4422:
This seems like a bug in javadoc generation: it produces this:
{noformat}
...
tr class=rowColor
td class=colFirsta
href=org/apache/lucene/index/package-summary.htmlorg.apache.lucene.index/a/td
td class=colLast
div class=blockCode to maintain and access indices.
!/div
/td
/tr
...
{noformat}
The javadocs linter is angry about that ! ... I don't think that's valid HTML.
Don't rely on the computer locale to generate javadocs
--
Key: LUCENE-4422
URL: https://issues.apache.org/jira/browse/LUCENE-4422
Project: Lucene - Core
Issue Type: Bug
Components: general/build, general/javadocs
Affects Versions: 5.0, 4.0
Environment: locale=fr_FR
Reporter: Adrien Grand
Assignee: Robert Muir
Priority: Minor
Fix For: 4.0
Attachments: LUCENE-4422.patch
With the fr_FR locale, javadoc 1.6.0_26 fails to generate correct HTML output
for the class-use files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4422) Don't rely on the computer locale to generate javadocs
[ https://issues.apache.org/jira/browse/LUCENE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461871#comment-13461871 ] Robert Muir commented on LUCENE-4422: - I committed this to trunk and 4.x. If we respin for some other reason, ill investigate backporting r1389442 to the release branch Don't rely on the computer locale to generate javadocs -- Key: LUCENE-4422 URL: https://issues.apache.org/jira/browse/LUCENE-4422 Project: Lucene - Core Issue Type: Bug Components: general/build, general/javadocs Affects Versions: 5.0, 4.0 Environment: locale=fr_FR Reporter: Adrien Grand Assignee: Robert Muir Priority: Minor Fix For: 4.0 Attachments: LUCENE-4422.patch With the fr_FR locale, javadoc 1.6.0_26 fails to generate correct HTML output for the class-use files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461860#comment-13461860 ] Christian Moen edited comment on SOLR-3876 at 9/25/12 2:54 AM: --- Thanks a lot for this, Jack. I'm afraid I don't know the overall status nor history of the 4.0 UI in IE9, but do you happen to know if this is a regression of it the UI has been generally broken for IE9 all along? To me it sounds quite important to get this fixed for 4.0 if it's a regression. I can help working some on this. was (Author: cm): Thanks a lot for this, Jack. I'm afraid I don't know the overall status nor history of the 4.0 UI in IE9, but do you happen to know if this is a regression of it the UI has been generally broken for IE9 all along? To me it sounds quite important to get this fixed for 4.0 and I can help working some on this. Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.0 Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461877#comment-13461877 ] Jack Krupansky commented on SOLR-3876: -- I primarily use Chrome, so I never actually tried the Admin UI in IE 9 until recently - see my comment on SOLR-3840 dated September 13th. As indicated there, I meant to file a separate Jira for this issue, but... it slipped my mind until a was reviewing the comments on SOLR-3840 this morning when someone commented on that issue. I wasn't even aware that I had IE 9 - Microsoft must have pushed an auto-update at some point. The Wikipedia says IE 9 was released back in 2011, but that doesn't say when it became the default update for Windows 7. In short, I don't know if this is a regression for IE 9. I'd assume that it isn't. I don't even know if it is a regression from IE 8. Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.0 Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-4410. - Resolution: Fixed committed to 4.x in revision 1389462. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.1, 5.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch, LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461889#comment-13461889 ] Christian Moen commented on SOLR-3876: -- The 4.0 UI wasn't developed with IE9 in mind so getting IE9 supported seems like a bigger effort. SOLR-3841 seems related to this issue and has been deferred to 4.1 so I'm suggesting that we do the same with this one as well. Please feel free to jump in with whatever comments you might have, steffkes. Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.1 Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3876) Solr Admin UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Moen updated SOLR-3876: - Fix Version/s: (was: 4.0) 4.1 Solr Admin UI is completely dysfunctional on IE 9 - Key: SOLR-3876 URL: https://issues.apache.org/jira/browse/SOLR-3876 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA, 4.0 Environment: Windows 7, IE 9 Reporter: Jack Krupansky Priority: Critical Fix For: 4.1 Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg The Solr Admin UI is completely dysfunctional on IE 9. See attached screen shot. I don't even see a collection1 button. But Admin UI is working fine in Google Chrome with same running instance of Solr. Currently running 4.0 RC0, but problem existed with 4.0-BETA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3877) backup and snapshooter scripts do not work.
Jim Musil created SOLR-3877: --- Summary: backup and snapshooter scripts do not work. Key: SOLR-3877 URL: https://issues.apache.org/jira/browse/SOLR-3877 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux Reporter: Jim Musil When trying to run the ./backup and ./snapshooter scripts, they do not work. It seems like they are looking for differently named files. Are these deprecated or unsupported? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3862) add remove as update option for atomically removing a value from a multivalued field
[ https://issues.apache.org/jira/browse/SOLR-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461902#comment-13461902 ] Jim Musil commented on SOLR-3862: - Personally, I'd like it to be remove by value. Even better, would be remove by regex. add remove as update option for atomically removing a value from a multivalued field -- Key: SOLR-3862 URL: https://issues.apache.org/jira/browse/SOLR-3862 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA Reporter: Jim Musil Currently you can atomically add a value to a multivalued field. It would be useful to be able to remove a value from a multivalued field. When you set a multivalued field to null, it destroys all values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-3862) add remove as update option for atomically removing a value from a multivalued field
[ https://issues.apache.org/jira/browse/SOLR-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461902#comment-13461902 ] Jim Musil edited comment on SOLR-3862 at 9/25/12 3:45 AM: -- Personally, I'd like it to be remove by value. Even better, would be remove by regex. I think the most intuitive method would be to remove globally from the list. was (Author: jimtronic): Personally, I'd like it to be remove by value. Even better, would be remove by regex. add remove as update option for atomically removing a value from a multivalued field -- Key: SOLR-3862 URL: https://issues.apache.org/jira/browse/SOLR-3862 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA Reporter: Jim Musil Currently you can atomically add a value to a multivalued field. It would be useful to be able to remove a value from a multivalued field. When you set a multivalued field to null, it destroys all values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-4409) implement javadocs linting with eclipse ecj compiler
[
https://issues.apache.org/jira/browse/LUCENE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler reopened LUCENE-4409:
---
Assignee: Uwe Schindler
The test has a whitespace in pathname problem. Also its not nice to permgen. I
have a patch fixing those 2 problems. It also prints a nice taskname instead of
[javac] on ANT output.
implement javadocs linting with eclipse ecj compiler
Key: LUCENE-4409
URL: https://issues.apache.org/jira/browse/LUCENE-4409
Project: Lucene - Core
Issue Type: Task
Components: general/build
Reporter: Robert Muir
Assignee: Uwe Schindler
Fix For: 4.1, 5.0
Attachments: LUCENE-4409.patch, LUCENE-4409.patch
today we have a lot of custom python scripts checking javadocs (checking for
missing stuff too).
Most of this is implemented by parsing html etc (some of this should stay
this way, like broken-link detection)
But actually the eclipse compiler can do most of this type of linting, and
has a lot of options for it. We can pull it via ivy and run it from the
command-line.
I tested this manually by adding a bogus throws clause to Codec.java,
downloading the ecj.jar from maven and running it manually:
{noformat}
rmuir@beast:~/workspace/lucene-trunk/lucene/core/src/java$ java -cp
~/Downloads/ecj-3.7.2.jar org.eclipse.jdt.internal.compiler.batch.Main
-source 1.6 -d none -enableJavadoc -properties
~/workspace/lucene-trunk/dev-tools/eclipse/.settings/org.eclipse.jdt.core.prefs
.
...
--
120. ERROR in
/home/rmuir/workspace/lucene-trunk/lucene/core/src/java/./org/apache/lucene/codecs/Codec.java
(at line 59)
* @throws IOException */
^^^
Javadoc: Exception IOException is not declared
--
{noformat}
here i specified -d none (don't generate class files), and essentially told
it to read the compiler warnings/errors options set in the dev-tools config.
For javadocs-lint we would want our own separate properties file that
disables the ordinary java warnings (because eclipse can warn/error/ignore on
lots of things, not just javadocs, and does by default).
Separately we could also use this to check/fail/warn on other things besides
javadoc...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
softCommitWithin ??
Hi, In 4.0, it was talked about defaulting the update request parameter ?commitWithin=nnn to do softCommit (SOLR-2193, SOLR-2565). Was that ever done, or is there a separate ?softCommitWithin=nnn option? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4409) implement javadocs linting with eclipse ecj compiler
[
https://issues.apache.org/jira/browse/LUCENE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4409:
--
Attachment: LUCENE-4409-componentdef.patch
Patch
- Uses componentdef to load the ECJ compiler, so the classloader can be reused
like with taskdef.
- It also adds taskname=ecj-lint als param to javac, so the log output is
nice.
- The compilearg/ has to use value=... instead of line, otherwise it breaks
with whitespace in the properties file path.
I will commit that soon, just doing final checks!
implement javadocs linting with eclipse ecj compiler
Key: LUCENE-4409
URL: https://issues.apache.org/jira/browse/LUCENE-4409
Project: Lucene - Core
Issue Type: Task
Components: general/build
Reporter: Robert Muir
Assignee: Uwe Schindler
Fix For: 4.1, 5.0
Attachments: LUCENE-4409-componentdef.patch, LUCENE-4409.patch,
LUCENE-4409.patch
today we have a lot of custom python scripts checking javadocs (checking for
missing stuff too).
Most of this is implemented by parsing html etc (some of this should stay
this way, like broken-link detection)
But actually the eclipse compiler can do most of this type of linting, and
has a lot of options for it. We can pull it via ivy and run it from the
command-line.
I tested this manually by adding a bogus throws clause to Codec.java,
downloading the ecj.jar from maven and running it manually:
{noformat}
rmuir@beast:~/workspace/lucene-trunk/lucene/core/src/java$ java -cp
~/Downloads/ecj-3.7.2.jar org.eclipse.jdt.internal.compiler.batch.Main
-source 1.6 -d none -enableJavadoc -properties
~/workspace/lucene-trunk/dev-tools/eclipse/.settings/org.eclipse.jdt.core.prefs
.
...
--
120. ERROR in
/home/rmuir/workspace/lucene-trunk/lucene/core/src/java/./org/apache/lucene/codecs/Codec.java
(at line 59)
* @throws IOException */
^^^
Javadoc: Exception IOException is not declared
--
{noformat}
here i specified -d none (don't generate class files), and essentially told
it to read the compiler warnings/errors options set in the dev-tools config.
For javadocs-lint we would want our own separate properties file that
disables the ordinary java warnings (because eclipse can warn/error/ignore on
lots of things, not just javadocs, and does by default).
Separately we could also use this to check/fail/warn on other things besides
javadoc...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4409) implement javadocs linting with eclipse ecj compiler
[
https://issues.apache.org/jira/browse/LUCENE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461928#comment-13461928
]
Robert Muir commented on LUCENE-4409:
-
+1, thanks for cleaning up. taskname is cool, i didn't like the log output but
didnt know about this.
implement javadocs linting with eclipse ecj compiler
Key: LUCENE-4409
URL: https://issues.apache.org/jira/browse/LUCENE-4409
Project: Lucene - Core
Issue Type: Task
Components: general/build
Reporter: Robert Muir
Assignee: Uwe Schindler
Fix For: 4.1, 5.0
Attachments: LUCENE-4409-componentdef.patch, LUCENE-4409.patch,
LUCENE-4409.patch
today we have a lot of custom python scripts checking javadocs (checking for
missing stuff too).
Most of this is implemented by parsing html etc (some of this should stay
this way, like broken-link detection)
But actually the eclipse compiler can do most of this type of linting, and
has a lot of options for it. We can pull it via ivy and run it from the
command-line.
I tested this manually by adding a bogus throws clause to Codec.java,
downloading the ecj.jar from maven and running it manually:
{noformat}
rmuir@beast:~/workspace/lucene-trunk/lucene/core/src/java$ java -cp
~/Downloads/ecj-3.7.2.jar org.eclipse.jdt.internal.compiler.batch.Main
-source 1.6 -d none -enableJavadoc -properties
~/workspace/lucene-trunk/dev-tools/eclipse/.settings/org.eclipse.jdt.core.prefs
.
...
--
120. ERROR in
/home/rmuir/workspace/lucene-trunk/lucene/core/src/java/./org/apache/lucene/codecs/Codec.java
(at line 59)
* @throws IOException */
^^^
Javadoc: Exception IOException is not declared
--
{noformat}
here i specified -d none (don't generate class files), and essentially told
it to read the compiler warnings/errors options set in the dev-tools config.
For javadocs-lint we would want our own separate properties file that
disables the ordinary java warnings (because eclipse can warn/error/ignore on
lots of things, not just javadocs, and does by default).
Separately we could also use this to check/fail/warn on other things besides
javadoc...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3878) NPE in CurrencyValue.parse() while issuing wildcard range query on a CurrencyField
Miklós Márton created SOLR-3878: --- Summary: NPE in CurrencyValue.parse() while issuing wildcard range query on a CurrencyField Key: SOLR-3878 URL: https://issues.apache.org/jira/browse/SOLR-3878 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 3.6.1 Reporter: Miklós Márton Priority: Minor According to the [wiki|http://wiki.apache.org/solr/CurrencyField#Querying] wildcard range queries are supported. In reality either of the following queries result in NPE using the example schema. - price_c:[* TO 1000] - price_c:[* TO 1000,USD] - price_c:[*,USD TO 1000,USD] - price_c:[1000 TO *] - price_c:[1000,USD TO *] - price_c:[1000,USD TO *] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4409) implement javadocs linting with eclipse ecj compiler
[
https://issues.apache.org/jira/browse/LUCENE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-4409.
---
Resolution: Fixed
Committed trunk revision: 1389491
Committed 4.x revision: 1389492
implement javadocs linting with eclipse ecj compiler
Key: LUCENE-4409
URL: https://issues.apache.org/jira/browse/LUCENE-4409
Project: Lucene - Core
Issue Type: Task
Components: general/build
Reporter: Robert Muir
Assignee: Uwe Schindler
Fix For: 4.1, 5.0
Attachments: LUCENE-4409-componentdef.patch, LUCENE-4409.patch,
LUCENE-4409.patch
today we have a lot of custom python scripts checking javadocs (checking for
missing stuff too).
Most of this is implemented by parsing html etc (some of this should stay
this way, like broken-link detection)
But actually the eclipse compiler can do most of this type of linting, and
has a lot of options for it. We can pull it via ivy and run it from the
command-line.
I tested this manually by adding a bogus throws clause to Codec.java,
downloading the ecj.jar from maven and running it manually:
{noformat}
rmuir@beast:~/workspace/lucene-trunk/lucene/core/src/java$ java -cp
~/Downloads/ecj-3.7.2.jar org.eclipse.jdt.internal.compiler.batch.Main
-source 1.6 -d none -enableJavadoc -properties
~/workspace/lucene-trunk/dev-tools/eclipse/.settings/org.eclipse.jdt.core.prefs
.
...
--
120. ERROR in
/home/rmuir/workspace/lucene-trunk/lucene/core/src/java/./org/apache/lucene/codecs/Codec.java
(at line 59)
* @throws IOException */
^^^
Javadoc: Exception IOException is not declared
--
{noformat}
here i specified -d none (don't generate class files), and essentially told
it to read the compiler warnings/errors options set in the dev-tools config.
For javadocs-lint we would want our own separate properties file that
disables the ordinary java warnings (because eclipse can warn/error/ignore on
lots of things, not just javadocs, and does by default).
Separately we could also use this to check/fail/warn on other things besides
javadoc...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3879) war file has javax.servlet-api jar bundled
Roman Shaposhnik created SOLR-3879:
--
Summary: war file has javax.servlet-api jar bundled
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Fix For: 4.0
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
+1, I ran my usual workflow on Solr, indexing example content and poking around. I did notice one issue in the /browse UI, and haven't researched when this happened, but after indexing the the Solr example docs (java -jar post.jar *.xml) I got this in the UI: In Stock: true jEOE: software search That jEOE should be Cat or Category instead. I'll open a JIRA. Cosmetic, though confusing. Erik On Sep 23, 2012, at 21:11 , Robert Muir wrote: Artifacts are here: http://s.apache.org/lusolr40rc0 Thanks, Robert -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3880) /browse jEOE should be Cat instead
Erik Hatcher created SOLR-3880:
--
Summary: /browse jEOE should be Cat instead
Key: SOLR-3880
URL: https://issues.apache.org/jira/browse/SOLR-3880
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: This was spotted in the 4.0 (RC0) build
Reporter: Erik Hatcher
Priority: Trivial
Fix For: 4.1, 5.0
The /browse UI, after indexing the example docs (java -jar post.jar *.xml),
shows:
{code}
In Stock: true
jEOE: software search
{code}
That jEOE is errant, originating from
example/solr/example/collection1/conf/velocity/product-doc.vm and should be
Cat or Category instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3880) /browse jEOE should be Cat instead
[
https://issues.apache.org/jira/browse/SOLR-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461963#comment-13461963
]
Erik Hatcher commented on SOLR-3880:
Looking at history, this appears to have snuck in via LUCENE-4362
/browse jEOE should be Cat instead
--
Key: SOLR-3880
URL: https://issues.apache.org/jira/browse/SOLR-3880
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: This was spotted in the 4.0 (RC0) build
Reporter: Erik Hatcher
Priority: Trivial
Fix For: 4.1, 5.0
The /browse UI, after indexing the example docs (java -jar post.jar *.xml),
shows:
{code}
In Stock: true
jEOE: software search
{code}
That jEOE is errant, originating from
example/solr/example/collection1/conf/velocity/product-doc.vm and should be
Cat or Category instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3881) frequent OOM in LanguageIdentifierUpdateProcessor
Rob Tulloh created SOLR-3881:
Summary: frequent OOM in LanguageIdentifierUpdateProcessor
Key: SOLR-3881
URL: https://issues.apache.org/jira/browse/SOLR-3881
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.0
Environment: CentOS 6.x, JDK 1.6, (java -server -Xms2G -Xmx2G
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=)
Reporter: Rob Tulloh
We are seeing frequent failures from Solr causing it to OOM. Here is the stack
trace we observe when this happens:
{noformat}
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
at java.lang.StringBuffer.append(StringBuffer.java:224)
at
org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.concatFields(LanguageIdentifierUpdateProcessor.java:286)
at
org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(LanguageIdentifierUpdateProcessor.java:189)
at
org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.processAdd(LanguageIdentifierUpdateProcessor.java:171)
at
org.apache.solr.handler.BinaryUpdateRequestHandler$2.update(BinaryUpdateRequestHandler.java:90)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:140)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:120)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:105)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186)
at
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:147)
at
org.apache.solr.handler.BinaryUpdateRequestHandler.parseAndLoadDocs(BinaryUpdateRequestHandler.java:100)
at
org.apache.solr.handler.BinaryUpdateRequestHandler.access$000(BinaryUpdateRequestHandler.java:47)
at
org.apache.solr.handler.BinaryUpdateRequestHandler$1.load(BinaryUpdateRequestHandler.java:58)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: VOTE: release 4.0
Running smokeTestRelease.py on Win7+Cygwin, I can't get past the Solr example
test under Java7.
I ran the smoke tester three times using Oracle v1.7.0_01 64-bit, and then two
times using Oracle v1.7.0_07 64-bit. Four out of the five runs failed on the
first Java7 Solr example test (from the unpacked .tgz distribution), while one
run passed the .tgz Solr example test, but then failed on the .zip Solr example
test.
All Java6 (v1.6.0_34) Solr example test runs always pass for me.
Here's the output from the most recent attempt - below I also have included the
corresponding solr-example.log:
-
Test Solr...
test basics...
get KEYS
0.1 MB
download apache-solr-4.0.0-src.tgz...
29.8 MB
verify md5/sha1 digests
verify sig
GPG: gpg: WARNING: using insecure memory!
verify trust
GPG: gpg: WARNING: using insecure memory!
GPG: gpg: WARNING: This key is not certified with a trusted signature!
download apache-solr-4.0.0.tgz...
102.8 MB
verify md5/sha1 digests
verify sig
GPG: gpg: WARNING: using insecure memory!
verify trust
GPG: gpg: WARNING: using insecure memory!
GPG: gpg: WARNING: This key is not certified with a trusted signature!
download apache-solr-4.0.0.zip...
107.0 MB
verify md5/sha1 digests
verify sig
GPG: gpg: WARNING: using insecure memory!
verify trust
GPG: gpg: WARNING: using insecure memory!
GPG: gpg: WARNING: This key is not certified with a trusted signature!
unpack apache-solr-4.0.0.tgz...
test solr example w/ Java 6...
start Solr instance
(log=/home/sarowe/temp/tmpDir/unpack/apache-solr-4.0.0/solr-example.log)...
startup done
test utf8...
index example docs...
run query...
stop server (SIGINT)...
test solr example w/ Java 7...
start Solr instance
(log=/home/sarowe/temp/tmpDir/unpack/apache-solr-4.0.0/solr-example.log)...
startup done
test utf8...
index example docs...
run query...
FAILED: response is:
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status0/intint
name=QTime0/intlst name=paramsstr
name=qvideo/str/lst/lstresult name=response numFound=0
start=0/result
/response
stop server (SIGINT)...
Traceback (most recent call last):
File dev-tools/scripts/smokeTestRelease.py, line 1121, in module
File dev-tools/scripts/smokeTestRelease.py, line 1071, in main
File dev-tools/scripts/smokeTestRelease.py, line 1113, in smokeTest
File dev-tools/scripts/smokeTestRelease.py, line 424, in unpack
File dev-tools/scripts/smokeTestRelease.py, line 540, in verifyUnpacked
File dev-tools/scripts/smokeTestRelease.py, line 612, in testSolrExample
RuntimeError: query on solr example instance failed
-
And the solr-example.log:
-
2012-09-24 14:08:56.153:INFO:oejs.Server:jetty-8.1.2.v20120308
2012-09-24 14:08:56.166:INFO:oejdp.ScanningAppProvider:Deployment monitor
C:\cygwin\home\sarowe\temp\tmpDir\unpack\apache-solr-4.0.0\example\contexts at
interval 0
2012-09-24 14:08:56.171:INFO:oejd.DeploymentManager:Deployable added:
C:\cygwin\home\sarowe\temp\tmpDir\unpack\apache-solr-4.0.0\example\contexts\solr.xml
2012-09-24 14:08:56.719:INFO:oejw.StandardDescriptorProcessor:NO JSP Support
for /solr, did not find org.apache.jasper.servlet.JspServlet
2012-09-24 14:08:56.737:INFO:oejsh.ContextHandler:started
o.e.j.w.WebAppContext{/solr,file:/C:/cygwin/home/sarowe/temp/tmpDir/unpack/apache-solr-4.0.0/example/solr-webapp/webapp/},C:\cygwin\home\sarowe\temp\tmpDir\unpack\apache-solr-4.0.0\example/webapps/solr.war
2012-09-24 14:08:56.737:INFO:oejsh.ContextHandler:started
o.e.j.w.WebAppContext{/solr,file:/C:/cygwin/home/sarowe/temp/tmpDir/unpack/apache-solr-4.0.0/example/solr-webapp/webapp/},C:\cygwin\home\sarowe\temp\tmpDir\unpack\apache-solr-4.0.0\example/webapps/solr.war
Sep 24, 2012 2:08:56 PM org.apache.solr.core.SolrResourceLoader locateSolrHome
INFO: JNDI not configured for solr (NoInitialContextEx)
Sep 24, 2012 2:08:56 PM org.apache.solr.core.SolrResourceLoader locateSolrHome
INFO: solr home defaulted to 'solr/' (could not find system property or JNDI)
Sep 24, 2012 2:08:56 PM org.apache.solr.core.SolrResourceLoader init
INFO: new SolrResourceLoader for deduced Solr Home: 'solr/'
Sep 24, 2012 2:08:56 PM org.apache.solr.servlet.SolrDispatchFilter init
INFO: SolrDispatchFilter.init()
Sep 24, 2012 2:08:56 PM org.apache.solr.core.SolrResourceLoader locateSolrHome
INFO: JNDI not configured for solr (NoInitialContextEx)
Sep 24, 2012 2:08:56 PM org.apache.solr.core.SolrResourceLoader locateSolrHome
INFO: solr home defaulted to 'solr/' (could not find system property or JNDI)
Sep 24, 2012 2:08:56 PM org.apache.solr.core.CoreContainer$Initializer
initialize
INFO: looking for solr.xml:
C:\cygwin\home\sarowe\temp\tmpDir\unpack\apache-solr-4.0.0\example\solr\solr.xml
Sep 24, 2012 2:08:56 PM org.apache.solr.core.CoreContainer init
INFO: New CoreContainer 1612487865
Sep 24,
Re: VOTE: release 4.0
On Mon, Sep 24, 2012 at 2:26 PM, Steven A Rowe sar...@syr.edu wrote: Running smokeTestRelease.py on Win7+Cygwin, I can't get past the Solr example test under Java7. I'm not really sure thats a reflection on this release candidate: I'm not sure the smoke tester works on windows. I think you may have to test manually. -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3877) backup and snapshooter scripts do not work.
[ https://issues.apache.org/jira/browse/SOLR-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-3877. Resolution: Fixed Fix Version/s: 5.0 4.1 Assignee: Hoss Man The wiki has noted for a while that the scripts have been superseded by the ReplicationHandler, and i thought the README file for the scripts said something similar -- but aparently there is no README file, so i added one. Committed revision 1389507. Committed revision 1389508. - 4x As far as your specific question about the scripts looking for differnetly named files/directories: the defaults do assume a very specific directory layout based on a single SolrCore setup, and this has never been changed because it's the most common setup for the types of legacy users who are likely to still want to use these scripts (ie: people who don't want to change much about their working setup) backup and snapshooter scripts do not work. --- Key: SOLR-3877 URL: https://issues.apache.org/jira/browse/SOLR-3877 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux Reporter: Jim Musil Assignee: Hoss Man Fix For: 4.1, 5.0 When trying to run the ./backup and ./snapshooter scripts, they do not work. It seems like they are looking for differently named files. Are these deprecated or unsupported? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3877) backup and snapshooter scripts do not work.
[ https://issues.apache.org/jira/browse/SOLR-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461991#comment-13461991 ] Jim Musil commented on SOLR-3877: - Awesome, thank you. Btw, I ran into this issue by searching for solr backup in google. The first result is http://wiki.apache.org/solr/SolrOperationsTools which does not mention anything about being superseded by the ReplicationHandler. I would edit, but I'm not quite sure what the wording should be. backup and snapshooter scripts do not work. --- Key: SOLR-3877 URL: https://issues.apache.org/jira/browse/SOLR-3877 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux Reporter: Jim Musil Assignee: Hoss Man Fix For: 4.1, 5.0 When trying to run the ./backup and ./snapshooter scripts, they do not work. It seems like they are looking for differently named files. Are these deprecated or unsupported? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3877) backup and snapshooter scripts do not work.
[ https://issues.apache.org/jira/browse/SOLR-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461999#comment-13461999 ] Hoss Man commented on SOLR-3877: Ah, ok ... thanks for the heads up. There's a note on the main page about these scripts, but you're right: nothing obvious in some of hte sub pages I'll take a stab at clarifying. backup and snapshooter scripts do not work. --- Key: SOLR-3877 URL: https://issues.apache.org/jira/browse/SOLR-3877 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux Reporter: Jim Musil Assignee: Hoss Man Fix For: 4.1, 5.0 When trying to run the ./backup and ./snapshooter scripts, they do not work. It seems like they are looking for differently named files. Are these deprecated or unsupported? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
Wow; that looks like a serious issue to me. - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/VOTE-release-4-0-tp4009770p4009941.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3880) /browse jEOE should be Cat instead
[
https://issues.apache.org/jira/browse/SOLR-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462004#comment-13462004
]
Erick Erickson commented on SOLR-3880:
--
G!
EOE = Erick Ogden Erickson. Somehow I checked that in when making that change
there were a massive number of files.
At any rate, I'll fix it later today and see if anything else snuck in
Thanks for catching this!
/browse jEOE should be Cat instead
--
Key: SOLR-3880
URL: https://issues.apache.org/jira/browse/SOLR-3880
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: This was spotted in the 4.0 (RC0) build
Reporter: Erik Hatcher
Priority: Trivial
Fix For: 4.1, 5.0
The /browse UI, after indexing the example docs (java -jar post.jar *.xml),
shows:
{code}
In Stock: true
jEOE: software search
{code}
That jEOE is errant, originating from
example/solr/example/collection1/conf/velocity/product-doc.vm and should be
Cat or Category instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3880) /browse jEOE should be Cat instead
[
https://issues.apache.org/jira/browse/SOLR-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-3880:
Assignee: Erick Erickson
/browse jEOE should be Cat instead
--
Key: SOLR-3880
URL: https://issues.apache.org/jira/browse/SOLR-3880
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: This was spotted in the 4.0 (RC0) build
Reporter: Erik Hatcher
Assignee: Erick Erickson
Priority: Trivial
Fix For: 4.1, 5.0
The /browse UI, after indexing the example docs (java -jar post.jar *.xml),
shows:
{code}
In Stock: true
jEOE: software search
{code}
That jEOE is errant, originating from
example/solr/example/collection1/conf/velocity/product-doc.vm and should be
Cat or Category instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462013#comment-13462013
]
Robert Muir commented on SOLR-3879:
---
I don't see a servlet-api.jar in the 3.6.0 war, but i do see it in 4.0.0 war.
I don't know anything about servlets, and would prefer if someone who knew
looked at this, I
just want to add my comment to please not commit any fix without a test (peek
inside the war
in smokeTestRelease.py and ensure no servlet-api jars or java.*/javax.* classes
inside jars in the war)
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Fix For: 4.0
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462021#comment-13462021
]
Uwe Schindler commented on SOLR-3879:
-
It is definitely a bug to include that jar file. I said it so many times,
servlet-api.jar is only a compile time dependecy and may not be in the war.
We should fix the packaging tasks, the binary release may also only contain
servlet.jar in the example folder next to jetty.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Fix For: 4.0
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462022#comment-13462022
]
Yonik Seeley commented on SOLR-3879:
bq. I don't see a servlet-api.jar in the 3.6.0 war, but i do see it in 4.0.0
war.
Sounds like a mistake that it's in 4.0
AFAIK, it's only for compiling against... the actual servlet container should
supply the API/implementation (but I'm not a servlet expert either).
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Fix For: 4.0
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated SOLR-3879:
Priority: Critical (was: Major)
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3880) /browse jEOE should be Cat instead
[
https://issues.apache.org/jira/browse/SOLR-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-3880:
---
Fix Version/s: 4.0
/browse jEOE should be Cat instead
--
Key: SOLR-3880
URL: https://issues.apache.org/jira/browse/SOLR-3880
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: This was spotted in the 4.0 (RC0) build
Reporter: Erik Hatcher
Assignee: Erick Erickson
Priority: Trivial
Fix For: 4.0, 4.1, 5.0
The /browse UI, after indexing the example docs (java -jar post.jar *.xml),
shows:
{code}
In Stock: true
jEOE: software search
{code}
That jEOE is errant, originating from
example/solr/example/collection1/conf/velocity/product-doc.vm and should be
Cat or Category instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3882) When a server is killed off, the cloud UI and zookeeper retains the session info forever
Jim Musil created SOLR-3882: --- Summary: When a server is killed off, the cloud UI and zookeeper retains the session info forever Key: SOLR-3882 URL: https://issues.apache.org/jira/browse/SOLR-3882 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux Reporter: Jim Musil Priority: Minor I'm testing out a multi-server cluster in Amazon EC2 with a dedicated stand alone zookeeper. When I terminate one of the nodes, the cloud UI and zookeeper retains the information. It shows it as grey, but it never removes it from the list. I understand why this may be for setups that have hard coded machine addresses, but in EC2 I would end up with dead sessions that have no hope of ever being brought back to life. If I spin up instances based on demand, I'll end up with a lot of dead sessions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4421) TermsFilter should use TermsEnum.seekExact not seekCeil
[
https://issues.apache.org/jira/browse/LUCENE-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462044#comment-13462044
]
Michael McCandless commented on LUCENE-4421:
+1
It's been discussed before ... but if the number of terms gets large-ish we
may want to build an Automaton and use Term.intersect.
But we should do this trivial fix first ...
TermsFilter should use TermsEnum.seekExact not seekCeil
---
Key: LUCENE-4421
URL: https://issues.apache.org/jira/browse/LUCENE-4421
Project: Lucene - Core
Issue Type: Improvement
Components: core/search
Reporter: David Smiley
Priority: Minor
TermsFilter line 82 is:
if (termsEnum.seekCeil(br) == TermsEnum.SeekStatus.FOUND) {
I expected use of seekExact(...) since the Filter shouldn't need to
potentially advance to the one after.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
[
https://issues.apache.org/jira/browse/SOLR-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3875:
---
Attachment: SOLR-3875.patch
patch with proposed test fix ... i'm still running the full test sweet, but
posting here for other folks to review early.
Document boost does not work correctly when using multi-valued fields
-
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA, 4.0, 4.1, 5.0
Reporter: Toke Eskildsen
Priority: Critical
Fix For: 4.0-BETA, 4.0, 4.1, 5.0
Attachments: SOLR-3875.patch
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15
values in a multi value field results in scores above 1,000,000,000, while a
boost of 0,5 results in scores below 0,001. The error is not present in Solr
3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example
mentioned above, the generated IndexableFields will get assigned boosts of 5,
5*5, 5*5... 5*5. As Lucene multiplies all the values, 15 instances of the
same field will have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the
sample documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for
_thomas_ matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result
of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the
moment, but we guess that a reversion to the old algorithm of assigning the
combined boost to the first instance and 1.0f to all subsequent instances
would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
[
https://issues.apache.org/jira/browse/SOLR-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3875:
---
Affects Version/s: (was: 4.0)
(was: 5.0)
(was: 4.1)
Fix Version/s: (was: 4.0-BETA)
removing 4.0-beta from the fix version (we don't go back in time) and any
affects versions that are in the future
Document boost does not work correctly when using multi-valued fields
-
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA
Reporter: Toke Eskildsen
Priority: Critical
Fix For: 4.0, 4.1, 5.0
Attachments: SOLR-3875.patch
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15
values in a multi value field results in scores above 1,000,000,000, while a
boost of 0,5 results in scores below 0,001. The error is not present in Solr
3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example
mentioned above, the generated IndexableFields will get assigned boosts of 5,
5*5, 5*5... 5*5. As Lucene multiplies all the values, 15 instances of the
same field will have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the
sample documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for
_thomas_ matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result
of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the
moment, but we guess that a reversion to the old algorithm of assigning the
combined boost to the first instance and 1.0f to all subsequent instances
would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462088#comment-13462088 ] Mark Miller commented on SOLR-3861: --- In IRC Hossman brought up the case where you don't use an update log - apparently auto commit promises a final commit before shutdown. We probably need better testing for that type of functionality, but we should deal with this. regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reopened SOLR-3861: --- regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3861: -- Fix Version/s: (was: 4.0) 4.1 regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462089#comment-13462089 ] Mark Miller commented on SOLR-3861: --- If someone wants to work on it now, we might be able to get it in any rc respin though. regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
[
https://issues.apache.org/jira/browse/SOLR-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462096#comment-13462096
]
Yonik Seeley commented on SOLR-3875:
+1, fix looks good!
Document boost does not work correctly when using multi-valued fields
-
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA
Reporter: Toke Eskildsen
Priority: Critical
Fix For: 4.0, 4.1, 5.0
Attachments: SOLR-3875.patch
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15
values in a multi value field results in scores above 1,000,000,000, while a
boost of 0,5 results in scores below 0,001. The error is not present in Solr
3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example
mentioned above, the generated IndexableFields will get assigned boosts of 5,
5*5, 5*5... 5*5. As Lucene multiplies all the values, 15 instances of the
same field will have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the
sample documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for
_thomas_ matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result
of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the
moment, but we guess that a reversion to the old algorithm of assigning the
combined boost to the first instance and 1.0f to all subsequent instances
would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
[
https://issues.apache.org/jira/browse/SOLR-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462105#comment-13462105
]
Mark Miller commented on SOLR-3875:
---
bq. patch with proposed test fix
+1
I applied the patch, inspected the fix, inspected the test. It looks right to
me.
I also ran all tests, and verified the new test fails as expected without the
fix.
Document boost does not work correctly when using multi-valued fields
-
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA
Reporter: Toke Eskildsen
Priority: Critical
Fix For: 4.0, 4.1, 5.0
Attachments: SOLR-3875.patch
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15
values in a multi value field results in scores above 1,000,000,000, while a
boost of 0,5 results in scores below 0,001. The error is not present in Solr
3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example
mentioned above, the generated IndexableFields will get assigned boosts of 5,
5*5, 5*5... 5*5. As Lucene multiplies all the values, 15 instances of the
same field will have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the
sample documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for
_thomas_ matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result
of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the
moment, but we guess that a reversion to the old algorithm of assigning the
combined boost to the first instance and 1.0f to all subsequent instances
would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4423) DocumentStoredFieldVisitor.binaryField ignores offset and length
Adrien Grand created LUCENE-4423: Summary: DocumentStoredFieldVisitor.binaryField ignores offset and length Key: LUCENE-4423 URL: https://issues.apache.org/jira/browse/LUCENE-4423 Project: Lucene - Core Issue Type: Bug Components: core/store Reporter: Adrien Grand This is no problem with SimpleText and Lucene40 since in their cases, offset is always 0 and length the length of the byte[] array, but it might break with custom codecs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
[
https://issues.apache.org/jira/browse/SOLR-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462115#comment-13462115
]
Michael McCandless commented on SOLR-3875:
--
Thanks Hoss, patch looks great!
Document boost does not work correctly when using multi-valued fields
-
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA
Reporter: Toke Eskildsen
Priority: Critical
Fix For: 4.0, 4.1, 5.0
Attachments: SOLR-3875.patch
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15
values in a multi value field results in scores above 1,000,000,000, while a
boost of 0,5 results in scores below 0,001. The error is not present in Solr
3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example
mentioned above, the generated IndexableFields will get assigned boosts of 5,
5*5, 5*5... 5*5. As Lucene multiplies all the values, 15 instances of the
same field will have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the
sample documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for
_thomas_ matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result
of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the
moment, but we guess that a reversion to the old algorithm of assigning the
combined boost to the first instance and 1.0f to all subsequent instances
would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shaposhnik updated SOLR-3879:
---
Attachment: SOLR-3879.patch.txt
Attached is the patch against trunk. When applied to the RC tarball it takes
care of the issue. Robert, can you please elaborate on how smokeTestRelease.py
relates to build/release? I'm pretty new to SOLR -- still learning.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3840) XML query response display is unreadable in Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462120#comment-13462120 ] Alexandre Rafalovitch commented on SOLR-3840: - I think this might be related to http://code.google.com/p/chromium/issues/detail?id=434 (see message at the bottom). Chrome can display XML, but not if it is in an iFrame. In addition, Firefox does display XML - with folding too - but it puts an ugly big banner on top with the 'missing style' message. Maybe the default return type should be changed at least for Admin. I vote for Ruby/indented. Not a default return type at the backend, just start the UI page with those options pre-selected. XML query response display is unreadable in Solr Admin Query UI --- Key: SOLR-3840 URL: https://issues.apache.org/jira/browse/SOLR-3840 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Environment: Google Chrome, Windows 7 - Firefox as well Reporter: Jack Krupansky Attachments: Query-UI-XML-unreadable.png If I execute a query in the Solr Admin Query UI, the default XML writer displays only the raw text of the Solr response XML element values, but none of the XML syntax itself, rendering the response display on the Query page almost completely useless. JSON, Ruby, et al display very reasonably formatted output, but XML does not. You can click on the icon next to the generated query URL to display the response in a browser tab of its own and then it does display the XML very reasonably, but the framed display on the query page is simply not readable. My recollection is that the old UI had this same problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3861: -- Attachment: SOLR-3861.patch I think something like this would work - a little hokey on the API side though. regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-3861.patch SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3841) Solr Admin Dashboard UI is completely dysfunctional on IE 9
[ https://issues.apache.org/jira/browse/SOLR-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462124#comment-13462124 ] Alexandre Rafalovitch commented on SOLR-3841: - Could, as a workaround, a Google Chrome embed be added? I don't particularly care if IE is ever supported, but this could be at least a partial fix. Solr Admin Dashboard UI is completely dysfunctional on IE 9 --- Key: SOLR-3841 URL: https://issues.apache.org/jira/browse/SOLR-3841 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA Environment: Windows 7, IE 9 Reporter: Jack Krupansky Fix For: 4.1 Attachments: Solr-Dashboard-Empty.png As the attached screenshot shows, the Solr Admin UI Dashboard is completely dysfunctional running on IE 9. With this same Solr, I see all dashboard functions fine on Google Chrome. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462127#comment-13462127 ] Mark Miller commented on SOLR-3861: --- Patch is a little off - doesn't pass tests - but shows the general idea that we probably want to improve on. regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-3861.patch SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3840) XML query response display is unreadable in Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462128#comment-13462128 ] Yonik Seeley commented on SOLR-3840: bq. I vote for Ruby/indented. JSON is much more standard... but ruby does have a big advantage for debugging in that newlines can be embedded in strings (common in explain output, exception traces, etc) and so it looks much better. XML query response display is unreadable in Solr Admin Query UI --- Key: SOLR-3840 URL: https://issues.apache.org/jira/browse/SOLR-3840 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Environment: Google Chrome, Windows 7 - Firefox as well Reporter: Jack Krupansky Attachments: Query-UI-XML-unreadable.png If I execute a query in the Solr Admin Query UI, the default XML writer displays only the raw text of the Solr response XML element values, but none of the XML syntax itself, rendering the response display on the Query page almost completely useless. JSON, Ruby, et al display very reasonably formatted output, but XML does not. You can click on the icon next to the generated query URL to display the response in a browser tab of its own and then it does display the XML very reasonably, but the framed display on the query page is simply not readable. My recollection is that the old UI had this same problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462132#comment-13462132
]
Robert Muir commented on SOLR-3879:
---
Roman your patch looks good.
smokeTestRelease.py (in the dev-tools/scripts directory) is a way to verify
release artifacts.
Its like a test for the release packaging itself, so it takes as input a URL
containing a release candidate (such as http://s.apache.org/lusolr40rc0),
and runs a bunch of tests on the files there and fails if something is wrong.
It can also be run against the current code checkout by running 'ant
nightly-smoke' from the top-level.
The key here is, if we don't test that the war doesn't contain stuff it
shouldn't, then the bug could come back for a future release.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462149#comment-13462149
]
Roman Shaposhnik commented on SOLR-3879:
Thanks! I'll update the patch shortly to include a test for this.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3883) distributed indexing forwards non-applicable request params
Yonik Seeley created SOLR-3883: -- Summary: distributed indexing forwards non-applicable request params Key: SOLR-3883 URL: https://issues.apache.org/jira/browse/SOLR-3883 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Yonik Seeley Priority: Blocker Fix For: 4.0 Including all of the original request params can cause really undesirable stuff to happen. Reported by Dan Sutton: http://find.searchhub.org/document/c21c27f20e115ce9 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462161#comment-13462161
]
Mark Miller commented on SOLR-3879:
---
bq. peek inside the war in smokeTestRelease.py and ensure no servlet-api jars
or java./javax. classes inside jars in the war
Yeah, I think this would be a general useful addition - a list of regex or
specific names for forbidden jars and class names.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4362) ban tab-indented source
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-4362:
---
Attachment: (was: LUCENE-4326_trunk.patch)
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Assignee: Erick Erickson
Fix For: 5.0, 4.0
Attachments: LUCENE-4362_4x.patch, LUCENE-4362_4x.patch,
LUCENE-4362_4x.patch, LUCENE-4362_4x.patch, LUCENE-4362_4x.patch,
LUCENE-4362_core.patch, LUCENE-4362.patch, LUCENE-4362.patch,
LUCENE-4362_trunk.patch, LUCENE-4362_trunk.patch, LUCENE-4362_trunk.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4362) ban tab-indented source
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462165#comment-13462165
]
Erick Erickson commented on LUCENE-4362:
There was a dyslexic patch that was far too easy to confuse with the real patch
(4326 rather than 4362 for trunk) so I removed it. It was never applied anyway.
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Assignee: Erick Erickson
Fix For: 5.0, 4.0
Attachments: LUCENE-4362_4x.patch, LUCENE-4362_4x.patch,
LUCENE-4362_4x.patch, LUCENE-4362_4x.patch, LUCENE-4362_4x.patch,
LUCENE-4362_core.patch, LUCENE-4362.patch, LUCENE-4362.patch,
LUCENE-4362_trunk.patch, LUCENE-4362_trunk.patch, LUCENE-4362_trunk.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
Folks, it looks like there definitely should be a respin, so please remember to back-port fixes that should go into 4.0 to the 4.0 branch in addition to the 4x branch. -Yonik http://lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Artifacts-trunk - Build # 2058 - Failure
Build: https://builds.apache.org/job/Lucene-Artifacts-trunk/2058/ No tests ran. Build Log: [...truncated 11419 lines...] ERROR: Failed to archive artifacts: lucene/dist/** hudson.util.IOException2: Failed to extract /home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/dist/** at hudson.FilePath.readFromTar(FilePath.java:1863) at hudson.FilePath.copyRecursiveTo(FilePath.java:1775) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:692) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:639) at hudson.model.Run.execute(Run.java:1527) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:238) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:116) at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257) at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223) at hudson.org.apache.tools.tar.TarInputStream.read(TarInputStream.java:345) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025) at org.apache.commons.io.IOUtils.copy(IOUtils.java:999) at hudson.util.IOUtils.copy(IOUtils.java:37) at hudson.FilePath.readFromTar(FilePath.java:1853) ... 11 more Publishing Javadoc FATAL: Unable to copy Javadoc from /home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/build/docs to /home/hudson/hudson/jobs/Lucene-Artifacts-trunk/javadoc hudson.util.IOException2: hudson.util.IOException2: Failed to extract /home/hudson/hudson-slave/workspace/Lucene-Artifacts-trunk/lucene/build/docs/**/* at hudson.FilePath.readFromTar(FilePath.java:1863) at hudson.FilePath.copyRecursiveTo(FilePath.java:1775) at hudson.FilePath.copyRecursiveTo(FilePath.java:1683) at hudson.tasks.JavadocArchiver.perform(JavadocArchiver.java:101) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:692) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:639) at hudson.model.Run.execute(Run.java:1527) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:238) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158) at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:116) at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257) at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223) at hudson.org.apache.tools.tar.TarInputStream.read(TarInputStream.java:345) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025) at org.apache.commons.io.IOUtils.copy(IOUtils.java:999) at hudson.util.IOUtils.copy(IOUtils.java:37) at hudson.FilePath.readFromTar(FilePath.java:1853) ... 12 more at hudson.FilePath.copyRecursiveTo(FilePath.java:1782) at hudson.FilePath.copyRecursiveTo(FilePath.java:1683) at hudson.tasks.JavadocArchiver.perform(JavadocArchiver.java:101) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:692) at
[jira] [Updated] (SOLR-3880) /browse jEOE should be Cat instead
[
https://issues.apache.org/jira/browse/SOLR-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-3880:
-
Attachment: SOLR-3880.patch
The whole line was an addition, just removed it.
/browse jEOE should be Cat instead
--
Key: SOLR-3880
URL: https://issues.apache.org/jira/browse/SOLR-3880
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: This was spotted in the 4.0 (RC0) build
Reporter: Erik Hatcher
Assignee: Erick Erickson
Priority: Trivial
Fix For: 4.0, 4.1, 5.0
Attachments: SOLR-3880.patch
The /browse UI, after indexing the example docs (java -jar post.jar *.xml),
shows:
{code}
In Stock: true
jEOE: software search
{code}
That jEOE is errant, originating from
example/solr/example/collection1/conf/velocity/product-doc.vm and should be
Cat or Category instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3880) /browse jEOE should be Cat instead
[
https://issues.apache.org/jira/browse/SOLR-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-3880.
--
Resolution: Fixed
Fix Version/s: (was: 5.0)
4x: 1389614
trunk: N/A
/browse jEOE should be Cat instead
--
Key: SOLR-3880
URL: https://issues.apache.org/jira/browse/SOLR-3880
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: This was spotted in the 4.0 (RC0) build
Reporter: Erik Hatcher
Assignee: Erick Erickson
Priority: Trivial
Fix For: 4.0, 4.1
Attachments: SOLR-3880.patch
The /browse UI, after indexing the example docs (java -jar post.jar *.xml),
shows:
{code}
In Stock: true
jEOE: software search
{code}
That jEOE is errant, originating from
example/solr/example/collection1/conf/velocity/product-doc.vm and should be
Cat or Category instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462177#comment-13462177
]
Uwe Schindler commented on SOLR-3879:
-
+1 to fix this issue!
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: VOTE: release 4.0
+1, If we do this, I would be happy to also fix the servlet-api.jar issue. If you want to add ecj-linter, I would also be happy, but that's not important, just nice to have! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik Seeley Sent: Monday, September 24, 2012 11:39 PM To: dev@lucene.apache.org Subject: Re: VOTE: release 4.0 Folks, it looks like there definitely should be a respin, so please remember to back-port fixes that should go into 4.0 to the 4.0 branch in addition to the 4x branch. -Yonik http://lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0
I'm voting for the respin as well. We should wait a brief time to let any other issues surface I think though. On Mon, Sep 24, 2012 at 5:58 PM, Uwe Schindler u...@thetaphi.de wrote: +1, If we do this, I would be happy to also fix the servlet-api.jar issue. If you want to add ecj-linter, I would also be happy, but that's not important, just nice to have! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik Seeley Sent: Monday, September 24, 2012 11:39 PM To: dev@lucene.apache.org Subject: Re: VOTE: release 4.0 Folks, it looks like there definitely should be a respin, so please remember to back-port fixes that should go into 4.0 to the 4.0 branch in addition to the 4x branch. -Yonik http://lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
