date:20120321

2012-03-21 Thread Stefan Matheis (steffkes) (Updated) (JIRA)

 One problem is we aren't getting a random seed here... this makes it
 impossible to debug, and i'm unable to reproduce locally :(

That's why we should all try hard to make LUCENE-3808 happen because
the master seed is reported there at the master build level, so you
know it even before any test started...

I'll try to provide a fix for this.

Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3895) Not getting random-seed/reproduce-with if a test fails from another thread

2012-03-21 Thread Dawid Weiss (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234185#comment-13234185
 ] 

Dawid Weiss commented on LUCENE-3895:
-

bq. Hopefully Dawid hates it and knows of a way to fix it cleanly 

It's fine for the trunk. It will be redundant in LUCENE-3808 (the seed is 
reported at master build level there + exceptions have an injected fake stack 
trace entry with the current master/test seed combination, even though the test 
seed is redundant most of the time because it's derived).



 Not getting random-seed/reproduce-with if a test fails from another thread
 --

 Key: LUCENE-3895
 URL: https://issues.apache.org/jira/browse/LUCENE-3895
 Project: Lucene - Java
  Issue Type: Bug
  Components: general/test
Affects Versions: 4.0
Reporter: Robert Muir
 Attachments: LUCENE-3895.patch


 See https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12822/console 
 as an example.
 This is at least affecting 4.0, maybe 3.x too

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3895) Not getting random-seed/reproduce-with if a test fails from another thread

2012-03-21 Thread Dawid Weiss (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated LUCENE-3895:


Attachment: LUCENE-3895.patch

Added a JUnit test to verify test seed is printed.

 Not getting random-seed/reproduce-with if a test fails from another thread
 --

 Key: LUCENE-3895
 URL: https://issues.apache.org/jira/browse/LUCENE-3895
 Project: Lucene - Java
  Issue Type: Bug
  Components: general/test
Affects Versions: 4.0
Reporter: Robert Muir
 Attachments: LUCENE-3895.patch, LUCENE-3895.patch


 See https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12822/console 
 as an example.
 This is at least affecting 4.0, maybe 3.x too

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3895) Not getting random-seed/reproduce-with if a test fails from another thread

2012-03-21 Thread Dawid Weiss (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234189#comment-13234189
 ] 

Dawid Weiss commented on LUCENE-3895:
-

Feel free to commit in (4.0/3.x?), Robert.

 Not getting random-seed/reproduce-with if a test fails from another thread
 --

 Key: LUCENE-3895
 URL: https://issues.apache.org/jira/browse/LUCENE-3895
 Project: Lucene - Java
  Issue Type: Bug
  Components: general/test
Affects Versions: 4.0
Reporter: Robert Muir
 Attachments: LUCENE-3895.patch, LUCENE-3895.patch


 See https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12822/console 
 as an example.
 This is at least affecting 4.0, maybe 3.x too

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3238) Sequel of Admin UI


 [ 
https://issues.apache.org/jira/browse/SOLR-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Matheis (steffkes) updated SOLR-3238:


Attachment: SOLR-3238.patch

Updated Patch, will commit soon

 Sequel of Admin UI
 --

 Key: SOLR-3238
 URL: https://issues.apache.org/jira/browse/SOLR-3238
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3238.patch, SOLR-3238.patch, solradminbug.png


 Catch-All Issue for all upcoming Bugs/Reports/Suggestions on the Admin UI

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-tests-only-trunk-java7 - Build # 2035 - Failure

2012-03-21 Thread Stefan Matheis (steffkes) (Commented) (JIRA)

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2035/

1 tests failed.
REGRESSION:  
org.apache.lucene.analysis.util.TestCharTokenizers.testCrossPlaneNormalization

Error Message:
Uncaught exception by thread: Thread[Thread-642,5,]

Stack Trace:
org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
 Uncaught exception by thread: Thread[Thread-642,5,]
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:60)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: org.junit.ComparisonFailure: term 0 expected:δ[δδδ] 
but was:δ[]
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:49)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:334)




Build Log (for compile errors):
[...truncated 3769 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Using term offsets for hit highlighting

2012-03-21 Thread Simon Willnauer

Alan, if you want I can just merge the branch up next week and we
iterate from there?

simon

On Tue, Mar 20, 2012 at 12:34 PM, Erick Erickson
erickerick...@gmail.com wrote:
 Yep, the first challenge is always getting the old patch(es) to apply.

 On Tue, Mar 20, 2012 at 4:09 AM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk wrote:
 Thanks for all the offers of help!  It looks as though most of the hard work 
 has already been done, which is exactly where I like to pick up projects.  
 :-)

 Maybe the best place to start would be for me to rebase the branch against 
 trunk, and see what still fits?  I think there have been some fairly major 
 changes in the internals since July last year.

 On 19 Mar 2012, at 17:07, Mike Sokolov wrote:

 I posted a patch with a Collector somewhat similar to what you described, 
 Alan - it's attached to one of the sub-issues 
 https://issues.apache.org/jira/browse/LUCENE-3318.   It is in a fairly 
 complete alpha state, but has seen no production use of course, since it 
 relies on the remainder of the unfinished work in that branch.  It works by 
 creating a TokenStream based on match positions returned from the query and 
 passing that to the existing Highlighter.  Please feel free to get in touch 
 if you decide to look into that and have questions.


 -Mike

 On 03/19/2012 11:51 AM, Simon Willnauer wrote:
 On Mon, Mar 19, 2012 at 4:50 PM, Uwe Schindleru...@thetaphi.de  wrote:

 Have you marked that for GSOC? Would be a good idea!

  yes I did

 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de



 -Original Message-
 From: Simon Willnauer [mailto:simon.willna...@googlemail.com]
 Sent: Monday, March 19, 2012 4:43 PM
 To: dev@lucene.apache.org
 Subject: Re: Using term offsets for hit highlighting

 Alan, you made my day!

 The branch is kind of outdated but I looked at it lately and I can 
 certainly help
 to get it up to speed. The feature in that branch is quite a big one and 
 its in a
 very early stage. Still I want to encourage you to take a look and work 
 on it. I
 promise all my help with the issues!

 let me know if you have questions!

 simon

 On Mon, Mar 19, 2012 at 3:52 PM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk  wrote:

 Cool, thanks Robert.  I'll take a look at the JIRA ticket.

 On 19 Mar 2012, at 14:44, Robert Muir wrote:


 On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk  wrote:

 Hello,

 The project I'm currently working on requires the reporting of exact
 hit positions from some pretty hairy queries, not all of which are
 covered by the existing highlighter modules.  I'm working round this
 by translating everything into SpanQueries, and using the getSpans()
 method to locate hits (I've extended the Spans interface to make
 term offsets available - see
 https://issues.apache.org/jira/browse/LUCENE-3826).  This works for
 our use-case, but isn't terribly efficient, and obviously isn't 
 applicable to

 non-Span queries.

 I've seen a bit of chatter on the list about using term offsets to
 provide accurate highlighting in Lucene.  I'm going to have a couple
 of weeks free in April, and I thought I might have a go at
 implementing this.  Mainly I'm wondering if there's already been
 thoughts about how to do it.  My current thoughts are to somehow
 extend the Weight and Scorer interface to make term offsets
 available; to get highlights for a given set of documents, you'd
 essentially run the query again, with a filter on just the documents
 you want highlighted, and have a custom collector that gets the term

 offsets in place of the scores.


 Hi Alan, Simon started some initial work on
 https://issues.apache.org/jira/browse/LUCENE-2878

 Some work and prototypes were done in a branch, but it might be
 lagging behind trunk a bit.

 Additionally at the time it was first done, I think we didn't yet
 support offsets in the postings lists.
 We've since added this and several codecs support it.

 --
 lucidimagination.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



 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands,

Re: Using term offsets for hit highlighting

2012-03-21 Thread Alan Woodward

That would be great, thanks!  I had a go at merging it last night, but there 
are a *lot* of changes that I haven't got my head round yet, so it was getting 
pretty messy.

On 21 Mar 2012, at 08:49, Simon Willnauer wrote:

 Alan, if you want I can just merge the branch up next week and we
 iterate from there?
 
 simon
 
 On Tue, Mar 20, 2012 at 12:34 PM, Erick Erickson
 erickerick...@gmail.com wrote:
 Yep, the first challenge is always getting the old patch(es) to apply.
 
 On Tue, Mar 20, 2012 at 4:09 AM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk wrote:
 Thanks for all the offers of help!  It looks as though most of the hard 
 work has already been done, which is exactly where I like to pick up 
 projects.  :-)
 
 Maybe the best place to start would be for me to rebase the branch against 
 trunk, and see what still fits?  I think there have been some fairly major 
 changes in the internals since July last year.
 
 On 19 Mar 2012, at 17:07, Mike Sokolov wrote:
 
 I posted a patch with a Collector somewhat similar to what you described, 
 Alan - it's attached to one of the sub-issues 
 https://issues.apache.org/jira/browse/LUCENE-3318.   It is in a fairly 
 complete alpha state, but has seen no production use of course, since it 
 relies on the remainder of the unfinished work in that branch.  It works 
 by creating a TokenStream based on match positions returned from the query 
 and passing that to the existing Highlighter.  Please feel free to get in 
 touch if you decide to look into that and have questions.
 
 
 -Mike
 
 On 03/19/2012 11:51 AM, Simon Willnauer wrote:
 On Mon, Mar 19, 2012 at 4:50 PM, Uwe Schindleru...@thetaphi.de  wrote:
 
 Have you marked that for GSOC? Would be a good idea!
 
  yes I did
 
 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
 
 
 
 -Original Message-
 From: Simon Willnauer [mailto:simon.willna...@googlemail.com]
 Sent: Monday, March 19, 2012 4:43 PM
 To: dev@lucene.apache.org
 Subject: Re: Using term offsets for hit highlighting
 
 Alan, you made my day!
 
 The branch is kind of outdated but I looked at it lately and I can 
 certainly help
 to get it up to speed. The feature in that branch is quite a big one 
 and its in a
 very early stage. Still I want to encourage you to take a look and work 
 on it. I
 promise all my help with the issues!
 
 let me know if you have questions!
 
 simon
 
 On Mon, Mar 19, 2012 at 3:52 PM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk  wrote:
 
 Cool, thanks Robert.  I'll take a look at the JIRA ticket.
 
 On 19 Mar 2012, at 14:44, Robert Muir wrote:
 
 
 On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk  wrote:
 
 Hello,
 
 The project I'm currently working on requires the reporting of exact
 hit positions from some pretty hairy queries, not all of which are
 covered by the existing highlighter modules.  I'm working round this
 by translating everything into SpanQueries, and using the getSpans()
 method to locate hits (I've extended the Spans interface to make
 term offsets available - see
 https://issues.apache.org/jira/browse/LUCENE-3826).  This works for
 our use-case, but isn't terribly efficient, and obviously isn't 
 applicable to
 
 non-Span queries.
 
 I've seen a bit of chatter on the list about using term offsets to
 provide accurate highlighting in Lucene.  I'm going to have a couple
 of weeks free in April, and I thought I might have a go at
 implementing this.  Mainly I'm wondering if there's already been
 thoughts about how to do it.  My current thoughts are to somehow
 extend the Weight and Scorer interface to make term offsets
 available; to get highlights for a given set of documents, you'd
 essentially run the query again, with a filter on just the documents
 you want highlighted, and have a custom collector that gets the term
 
 offsets in place of the scores.
 
 
 Hi Alan, Simon started some initial work on
 https://issues.apache.org/jira/browse/LUCENE-2878
 
 Some work and prototypes were done in a branch, but it might be
 lagging behind trunk a bit.
 
 Additionally at the time it was first done, I think we didn't yet
 support offsets in the postings lists.
 We've since added this and several codecs support it.
 
 --
 lucidimagination.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

[jira] [Commented] (SOLR-3238) Sequel of Admin UI


[ 
https://issues.apache.org/jira/browse/SOLR-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234226#comment-13234226
 ] 

Stefan Matheis (steffkes) commented on SOLR-3238:
-

Committed in revision 1303326

 Sequel of Admin UI
 --

 Key: SOLR-3238
 URL: https://issues.apache.org/jira/browse/SOLR-3238
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3238.patch, SOLR-3238.patch, solradminbug.png


 Catch-All Issue for all upcoming Bugs/Reports/Suggestions on the Admin UI

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3238) Sequel of Admin UI

2012-03-21 Thread Stefan Matheis (steffkes) (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234227#comment-13234227
 ] 

Stefan Matheis (steffkes) commented on SOLR-3238:
-

bq. New Issue?
Vadim, i think that would make sense yes :)

The Code which shows the error message you've mentioned on the first comment, 
is this one: 
https://github.com/steffkes/solr-admin/blob/master/js/scripts/app.js#L212 - 
it's requesting {{/admin/system}}

 Sequel of Admin UI
 --

 Key: SOLR-3238
 URL: https://issues.apache.org/jira/browse/SOLR-3238
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3238.patch, SOLR-3238.patch, solradminbug.png


 Catch-All Issue for all upcoming Bugs/Reports/Suggestions on the Admin UI

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3174) Visualize Cluster State

2012-03-21 Thread Stefan Matheis (steffkes) (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234230#comment-13234230
 ] 

Stefan Matheis (steffkes) commented on SOLR-3174:
-

So, d3-samples finally arrived ;o

Tree: [small|http://files.mathe.is/solr-admin/cloud-state/d3/], 
[large|http://files.mathe.is/solr-admin/cloud-state/d3/index-18.html]
Radial: [small|http://files.mathe.is/solr-admin/cloud-state/d3-radial/], 
[large|http://files.mathe.is/solr-admin/cloud-state/d3-radial/index-18.html]

I'll go with this for the first time .. and we'll see how good it fits our 
needs :)

 Visualize Cluster State
 ---

 Key: SOLR-3174
 URL: https://issues.apache.org/jira/browse/SOLR-3174
 Project: Solr
  Issue Type: New Feature
  Components: web gui
Reporter: Ryan McKinley

 It would be great to visualize the cluster state in the new UI. 
 See Mark's wish:
 https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3877) Lucene should not call System.out.println

2012-03-21 Thread Greg Bowyer (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Bowyer updated LUCENE-3877:


Attachment: IllegalSystemTest.java
IllegalSystemTest.java

I took a guess that one way would be to replace the System IO streams with ones 
that will throw exceptions.

It requires cglib, and might (due to the abuse of sun.reflect.Reflection to get 
the callee efficiently) be sun hotspot specific.

I guess this is not perfect, it would only error out if the code is called

If there is thought to this being a good thing I could look into how to wire it 
up to the unit-tests 

 Lucene should not call System.out.println
 -

 Key: LUCENE-3877
 URL: https://issues.apache.org/jira/browse/LUCENE-3877
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 3.6, 4.0

 Attachments: IllegalSystemTest.java


 We seem to have accumulated a few random sops...
 Eg, PairOutputs.java (oal.util.fst) and MultiDocValues.java, at least.
 Can we somehow detect (eg, have a test failure) if we accidentally leave 
 errant System.out.println's (leftover from debugging)...?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3877) Lucene should not call System.out.println

2012-03-21 Thread Greg Bowyer (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Bowyer updated LUCENE-3877:


Attachment: (was: IllegalSystemTest.java)

 Lucene should not call System.out.println
 -

 Key: LUCENE-3877
 URL: https://issues.apache.org/jira/browse/LUCENE-3877
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 3.6, 4.0

 Attachments: IllegalSystemTest.java


 We seem to have accumulated a few random sops...
 Eg, PairOutputs.java (oal.util.fst) and MultiDocValues.java, at least.
 Can we somehow detect (eg, have a test failure) if we accidentally leave 
 errant System.out.println's (leftover from debugging)...?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] Solr-trunk - Build # 1800 - Still Failing

Build: https://builds.apache.org/job/Solr-trunk/1800/

1 tests failed.
REGRESSION:  org.apache.solr.TestDistributedSearch.testDistribSearch

Error Message:
Uncaught exception by thread: Thread[Thread-1022,5,]

Stack Trace:
org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
 Uncaught exception by thread: Thread[Thread-1022,5,]
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:60)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: http://localhost:23797/solr
at 
org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:374)
Caused by: org.apache.solr.client.solrj.SolrServerException: 
http://localhost:23797/solr
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:496)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:251)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90)
at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:312)
at 
org.apache.solr.TestDistributedSearch$1.run(TestDistributedSearch.java:369)
Caused by: org.apache.commons.httpclient.ConnectTimeoutException: The host did 
not accept the connection within timeout of 100 ms
at 
org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:155)
at 
org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125)
at 
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at 
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:426)
... 4 more
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
at java.net.Socket.connect(Socket.java:546)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at

[jira] [Updated] (LUCENE-3877) Lucene should not call System.out.println

2012-03-21 Thread Greg Bowyer (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Bowyer updated LUCENE-3877:


Attachment: IllegalSystemTest.java

Helps if I upload the right version

 Lucene should not call System.out.println
 -

 Key: LUCENE-3877
 URL: https://issues.apache.org/jira/browse/LUCENE-3877
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 3.6, 4.0

 Attachments: IllegalSystemTest.java, IllegalSystemTest.java


 We seem to have accumulated a few random sops...
 Eg, PairOutputs.java (oal.util.fst) and MultiDocValues.java, at least.
 Can we somehow detect (eg, have a test failure) if we accidentally leave 
 errant System.out.println's (leftover from debugging)...?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: r1303234 - /lucene/dev/branches/branch_3x/lucene/test-framework/src/java/org/apache/lucene/analysis/MockReaderWrapper.java

2012-03-21 Thread Michael McCandless

Woops, thanks Rob!

Mike McCandless

http://blog.mikemccandless.com

On Tue, Mar 20, 2012 at 8:30 PM,  rm...@apache.org wrote:
 Author: rmuir
 Date: Wed Mar 21 00:30:41 2012
 New Revision: 1303234

 URL: http://svn.apache.org/viewvc?rev=1303234view=rev
 Log:
 LUCENE-3894: svn copy missing file from trunk

 Added:
    
 lucene/dev/branches/branch_3x/lucene/test-framework/src/java/org/apache/lucene/analysis/MockReaderWrapper.java
      - copied unchanged from r1303233, 
 lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/analysis/MockReaderWrapper.java


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-3898) possible SynonymFilter bug: hudson fail

2012-03-21 Thread Michael McCandless (Assigned) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless reassigned LUCENE-3898:
--

Assignee: Michael McCandless

 possible SynonymFilter bug: hudson fail
 ---

 Key: LUCENE-3898
 URL: https://issues.apache.org/jira/browse/LUCENE-3898
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
Assignee: Michael McCandless

 See https://builds.apache.org/job/Lucene-trunk/1867/consoleText (no seed)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-tests-only-trunk-java7 - Build # 2036 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2036/

1 tests failed.
FAILED:  org.apache.lucene.analysis.icu.TestICUFoldingFilter.testRandomStrings

Error Message:
Uncaught exception by thread: Thread[Thread-1,5,]

Stack Trace:
org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
 Uncaught exception by thread: Thread[Thread-1,5,]
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:60)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: org.junit.ComparisonFailure: term 0 expected:[]k but was:[]k
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:49)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:334)




Build Log (for compile errors):
[...truncated 3950 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3898) possible SynonymFilter bug: hudson fail

2012-03-21 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234263#comment-13234263
 ] 

Michael McCandless commented on LUCENE-3898:


I can't provoke this failure yet... (just beasting the test).

 possible SynonymFilter bug: hudson fail
 ---

 Key: LUCENE-3898
 URL: https://issues.apache.org/jira/browse/LUCENE-3898
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
Assignee: Michael McCandless

 See https://builds.apache.org/job/Lucene-trunk/1867/consoleText (no seed)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3897) KuromojiTokenizer fails with large docs

2012-03-21 Thread Christian Moen (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234268#comment-13234268
 ] 

Christian Moen commented on LUCENE-3897:


The assertion suggests that backtracking for some reason wants to go past its 
previous position.





 KuromojiTokenizer fails with large docs
 ---

 Key: LUCENE-3897
 URL: https://issues.apache.org/jira/browse/LUCENE-3897
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
 Fix For: 3.6, 4.0


 just shoving largeish random docs triggers asserts like:
 {noformat}
 [junit] Caused by: java.lang.AssertionError: backPos=4100 vs 
 lastBackTracePos=5120
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.backtrace(KuromojiTokenizer.java:907)
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.parse(KuromojiTokenizer.java:756)
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.incrementToken(KuromojiTokenizer.java:403)
 [junit]   at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:404)
 {noformat}
 But, you get no seed...
 I'll commit the test case and @Ignore it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-tests-only-trunk - Build # 12829 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12829/

1 tests failed.
REGRESSION:  
org.apache.lucene.analysis.util.TestCharTokenizers.testCrossPlaneNormalization2

Error Message:
term 0 expected:[] but was:[]

Stack Trace:
org.junit.ComparisonFailure: term 0 expected:[] but was:[]
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:342)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:298)
at 
org.apache.lucene.analysis.util.TestCharTokenizers.testCrossPlaneNormalization2(TestCharTokenizers.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)




Build Log (for compile errors):
[...truncated 3123 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12828 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12828/

1 tests failed.
REGRESSION:  org.apache.lucene.analysis.TestAnalyzers.testRandomStrings

Error Message:
Uncaught exception by thread: Thread[Thread-25,5,]

Stack Trace:
org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
 Uncaught exception by thread: Thread[Thread-25,5,]
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:59)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:506)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:50)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:19)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: org.junit.ComparisonFailure: term 0 expected:[] but was:[]
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:49)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:334)




Build Log (for compile errors):
[...truncated 9942 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3896) CharTokenizer has bugs for large documents.

2012-03-21 Thread Michael McCandless (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-3896:
---

Attachment: LUCENE-3896.patch

OK I think the problem here was the spoon-feeder would feed 1 character, and 
that 1 character is a high-surrogate.  In that case, CharacterUtils.fill was 
returning 0, but I think should re-attempt the read to pull more chars?

Attached patch seems to fix it... not sure we can do it cleaner though.

 CharTokenizer has bugs for large documents.
 ---

 Key: LUCENE-3896
 URL: https://issues.apache.org/jira/browse/LUCENE-3896
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
Priority: Blocker
 Attachments: LUCENE-3896.patch, LUCENE-3896.patch


 Initially found by hudson from additional testing added in LUCENE-3894, but 
 currently not reproducable (see LUCENE-3895).
 But its easy to reproduce for a simple single-threaded case in 
 TestDuelingAnalyzers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2020) HttpComponentsSolrServer

2012-03-21 Thread Sami Siren (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sami Siren updated SOLR-2020:
-

Attachment: SOLR-2020.patch

Few more small fixes. I think this is getting close to be committed.

 HttpComponentsSolrServer
 

 Key: SOLR-2020
 URL: https://issues.apache.org/jira/browse/SOLR-2020
 Project: Solr
  Issue Type: New Feature
  Components: clients - java
Affects Versions: 1.4.1
 Environment: Any
Reporter: Chantal Ackermann
Priority: Minor
 Fix For: 4.0

 Attachments: HttpComponentsSolrServer.java, 
 HttpComponentsSolrServerTest.java, SOLR-2020-HttpSolrServer.patch, 
 SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch


 Implementation of SolrServer that uses the Apache Http Components framework.
 Http Components (http://hc.apache.org/) is the successor of Commons 
 HttpClient and thus HttpComponentsSolrServer would be a successor of 
 CommonsHttpSolrServer, in the future.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3259) Solr 4 aesthetics

2012-03-21 Thread Erick Erickson (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234283#comment-13234283
 ] 

Erick Erickson commented on SOLR-3259:
--

bq:   that kind of directory structure would have made running the main 
example (whatever we might have called it) much harder then java -jar 
start.jar because it would have required specifying solr.solr.home.

And I totally agree that the less frustrating we make startup for a new person 
the better. Could we solve it by providing some number of startup scripts? Each 
is stupid-simple java -Dsolr.solr.home=blahblah -jar start.jar. Or even a 
shell script that took a parameter that defaulted to a simple, single core

 Solr 4 aesthetics
 -

 Key: SOLR-3259
 URL: https://issues.apache.org/jira/browse/SOLR-3259
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Fix For: 4.0


 Solr 4 will be a huge new release... we should take this opportunity to 
 improve the out-of-the-box experience.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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

Impossibility to pass filedName to analysers through TokenizerChain::getStream()

2012-03-21 Thread Egor Pahomov

I have different stop-word dictionaries per field, but all these fields
are captured by the single dynamic field i.e. single field type i.e. single
analyser.

It seems I need an improved TokenFilter, which is aware of the field
name, which it analyzes. Now filedName is passed into
TokenizerChain.getStream(), but it's not used there. How I can pass
filedName to token filters?

I'm thinking of adding a new method TokenStream create(String field,
TokenStream input) into TokenFilterFactory interface, then implement it in
BaseTokenFilterFactory via calling the single argument create(TokenStream
input). After that I'd be able to pass fieldName to TokenFilterFactory in
TokenizerChain.getStream(String fieldName, Reader reader). As an
alternative I can introduce FieldAwareTokenFilterFactory interface with two
args create() and use instanceof in TokenizerChain.getStream().
Is it a good solution for my problem?

Egor

[JENKINS-MAVEN] Lucene-Solr-Maven-3.x #433: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-3.x/433/

1 tests failed.
REGRESSION:  org.apache.lucene.analysis.TestAnalyzers.testRandomStrings

Error Message:
term 0 expected:礲[]س礲㰱Ҧʭ䂦➶C렎梈 but was:礲㰱礲[?]س礲㰱礲㰱Ҧʭ䂦➶C렎梈

Stack Trace:
org.junit.ComparisonFailure: term 0 expected:礲[]س㰱Ҧʭ䂦➶C렎梈 but 
was:礲[?]س㰱Ҧʭ䂦➶C렎梈
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:342)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:298)
at 
org.apache.lucene.analysis.TestAnalyzers.testRandomStrings(TestAnalyzers.java:227)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:626)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:532)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:20)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:448)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:50)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:506)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:50)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:19)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at 
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at

[jira] [Commented] (LUCENE-3895) Not getting random-seed/reproduce-with if a test fails from another thread

2012-03-21 Thread Martijn van Groningen (Resolved) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234313#comment-13234313
 ] 

Robert Muir commented on LUCENE-3895:
-

Thanks Dawid (and also for the cool test!). I'll commit soon.

 Not getting random-seed/reproduce-with if a test fails from another thread
 --

 Key: LUCENE-3895
 URL: https://issues.apache.org/jira/browse/LUCENE-3895
 Project: Lucene - Java
  Issue Type: Bug
  Components: general/test
Affects Versions: 4.0
Reporter: Robert Muir
 Attachments: LUCENE-3895.patch, LUCENE-3895.patch


 See https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12822/console 
 as an example.
 This is at least affecting 4.0, maybe 3.x too

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3444) Distinct field value count per group


 [ 
https://issues.apache.org/jira/browse/LUCENE-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martijn van Groningen resolved LUCENE-3444.
---

   Resolution: Fixed
Lucene Fields:   (was: New)

Committed to trunk.

 Distinct field value count per group
 

 Key: LUCENE-3444
 URL: https://issues.apache.org/jira/browse/LUCENE-3444
 Project: Lucene - Java
  Issue Type: New Feature
  Components: modules/grouping
Reporter: Martijn van Groningen
 Fix For: 4.0

 Attachments: LUCENE-3444.patch, LUCENE-3444.patch, LUCENE-3444.patch, 
 LUCENE-3444.patch


 Support a second pass collector that counts unique field values of a field 
 per group.
 This is just one example of group statistics that one might want.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3896) CharTokenizer has bugs for large documents.

2012-03-21 Thread Michael McCandless (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-3896:
---

Attachment: LUCENE-3896.patch

Improved the patch a bit; ant test in modules/analysis passes (at least 
once!).

I think it's ready...

 CharTokenizer has bugs for large documents.
 ---

 Key: LUCENE-3896
 URL: https://issues.apache.org/jira/browse/LUCENE-3896
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
Priority: Blocker
 Attachments: LUCENE-3896.patch, LUCENE-3896.patch, LUCENE-3896.patch


 Initially found by hudson from additional testing added in LUCENE-3894, but 
 currently not reproducable (see LUCENE-3895).
 But its easy to reproduce for a simple single-threaded case in 
 TestDuelingAnalyzers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3895) Not getting random-seed/reproduce-with if a test fails from another thread

2012-03-21 Thread Robert Muir (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-3895.
-

   Resolution: Fixed
Fix Version/s: 4.0
   3.6

I committed the fix. Dawid has a cleaner solution (the new runner) long-term.

 Not getting random-seed/reproduce-with if a test fails from another thread
 --

 Key: LUCENE-3895
 URL: https://issues.apache.org/jira/browse/LUCENE-3895
 Project: Lucene - Java
  Issue Type: Bug
  Components: general/test
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3895.patch, LUCENE-3895.patch


 See https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12822/console 
 as an example.
 This is at least affecting 4.0, maybe 3.x too

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 12829 - Failure

This is LUCENE-3896

On Wed, Mar 21, 2012 at 6:42 AM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12829/

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.analysis.util.TestCharTokenizers.testCrossPlaneNormalization2

 Error Message:
 term 0 expected:[] but was:[]

 Stack Trace:
 org.junit.ComparisonFailure: term 0 expected:[] but was:[]
        at org.junit.Assert.assertEquals(Assert.java:125)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:342)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:298)
        at 
 org.apache.lucene.analysis.util.TestCharTokenizers.testCrossPlaneNormalization2(TestCharTokenizers.java:177)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
        at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
        at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
        at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
        at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
        at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
        at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
        at 
 org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
        at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
        at 
 org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
        at 
 org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
        at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
        at org.junit.rules.RunRules.evaluate(RunRules.java:18)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
        at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
        at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
        at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
        at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
        at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
        at 
 org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
        at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
        at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
        at org.junit.rules.RunRules.evaluate(RunRules.java:18)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
        at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)




 Build Log (for compile errors):
 [...truncated 3123 lines...]




 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org



-- 
lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2037 - Still Failing

This is LUCENE-3896. The test should be using MockTokenizer instead of
Whitespace anyway. I'll switch it over.

On Wed, Mar 21, 2012 at 7:29 AM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2037/

 1 tests failed.
 FAILED:  org.apache.lucene.analysis.icu.TestICUFoldingFilter.testRandomStrings

 Error Message:
 Uncaught exception by thread: Thread[Thread-1,5,]

 Stack Trace:
 org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
  Uncaught exception by thread: Thread[Thread-1,5,]
        at 
 org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:60)
        at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
        at org.junit.rules.RunRules.evaluate(RunRules.java:18)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
        at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
        at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
        at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
        at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
        at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
        at 
 org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
        at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
        at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
        at org.junit.rules.RunRules.evaluate(RunRules.java:18)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
        at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
 Caused by: org.junit.ComparisonFailure: term 0 expected:[]vл䡭ꮄa桸t but 
 was:[]vл䡭ꮄa桸t
        at org.junit.Assert.assertEquals(Assert.java:125)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:49)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:334)




 Build Log (for compile errors):
 [...truncated 3895 lines...]




 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org



-- 
lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2921) Make any Filters, Tokenizers and CharFilters implement MultiTermAwareComponent if they should

[
https://issues.apache.org/jira/browse/SOLR-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234343#comment-13234343
]

Robert Muir commented on SOLR-2921:
---

{quote}
I guess I'm at a loss as to how to write tests for the various filters and
tokenizers I listed, which is why I'm reluctant to just make them
MultTermAwareComponents.
{quote}

Well, none of them are going to work perfectly with wildcards etc anyway, and
we already have:
* tests that these filters do what they should
* tests that this MultiTerm stuff works

Looking at your 'quick cull' list i think these will 'generally work'. Sure I
could list corner cases for maybe
half of them right off the top of my head, but we already know its not going to
work perfectly. These aren't bugs
in the filters if they don't work 100% right when given query syntax instead of
text, and its not bugs if they
have context-sensitive rules which won't work the way people expect with
patterns.

So I don't think we need tests that show their half-way broken behavior? This
is sort of a best-effort thing anyway.

Make any Filters, Tokenizers and CharFilters implement
MultiTermAwareComponent if they should
-

Key: SOLR-2921
URL: https://issues.apache.org/jira/browse/SOLR-2921
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 3.6, 4.0
Environment: All
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor

SOLR-2438 creates a new MultiTermAwareComponent interface. This allows Solr
to automatically assemble a multiterm analyzer that does the right thing
vis-a-vis transforming the individual terms of a multi-term query at query
time. Examples are: lower casing, folding accents, etc. Currently
(27-Nov-2011), the following classes implement MultiTermAwareComponent:
* ASCIIFoldingFilterFactory
* LowerCaseFilterFactory
* LowerCaseTokenizerFactory
* MappingCharFilterFactory
* PersianCharFilterFactory
When users put any of the above in their query analyzer, Solr will do the
right thing at query time and the perennial question users have, why didn't
my wildcard query automatically lower-case (or accent fold or) my terms?
will be gone. Die question die!
But taking a quick look, for instance, at the various FilterFactories that
exist, there are a number of possibilities that *might* be good candidates
for implementing MultiTermAwareComponent. But I really don't understand the
correct behavior here well enough to know whether these should implement the
interface or not. And this doesn't include other CharFilters or Tokenizers.
Actually implementing the interface is often trivial, see the classes above
for examples. Note that LowerCaseTokenizerFactory returns a *Filter*, which
is the right thing in this case.
Here is a quick cull of the Filters that, just from their names, might be
candidates. If anyone wants to take any of them on, that would be great. If
all you can do is provide test cases, I could probably do the code part, just
let me know.
ArabicNormalizationFilterFactory
GreekLowerCaseFilterFactory
HindiNormalizationFilterFactory
ICUFoldingFilterFactory
ICUNormalizer2FilterFactory
ICUTransformFilterFactory
IndicNormalizationFilterFactory
ISOLatin1AccentFilterFactory
PersianNormalizationFilterFactory
RussianLowerCaseFilterFactory
TurkishLowerCaseFilterFactory

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-tests-only-3.x - Build # 12830 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12830/

1 tests failed.
REGRESSION:  org.apache.lucene.analysis.TestAnalyzers.testRandomStrings

Error Message:
Uncaught exception by thread: Thread[Thread-16,5,]

Stack Trace:
org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
 Uncaught exception by thread: Thread[Thread-16,5,]
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:82)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:506)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:73)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:36)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:37)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: org.junit.ComparisonFailure: term 0 expected:[] but was:[]
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:49)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:334)




Build Log (for compile errors):
[...truncated 9966 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3896) CharTokenizer has bugs for large documents.

2012-03-21 Thread Robert Muir (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-3896:


Fix Version/s: 4.0
   3.6

 CharTokenizer has bugs for large documents.
 ---

 Key: LUCENE-3896
 URL: https://issues.apache.org/jira/browse/LUCENE-3896
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
Priority: Blocker
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3896.patch, LUCENE-3896.patch, LUCENE-3896.patch


 Initially found by hudson from additional testing added in LUCENE-3894, but 
 currently not reproducable (see LUCENE-3895).
 But its easy to reproduce for a simple single-threaded case in 
 TestDuelingAnalyzers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 12830 - Failure

This is still https://issues.apache.org/jira/browse/LUCENE-3896 (hasnt
been backported yet).

If Mike doesn't have the time i'll backport his trunk commit.

On Wed, Mar 21, 2012 at 9:49 AM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12830/

 1 tests failed.
 REGRESSION:  org.apache.lucene.analysis.TestAnalyzers.testRandomStrings

 Error Message:
 Uncaught exception by thread: Thread[Thread-16,5,]

 Stack Trace:
 org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
  Uncaught exception by thread: Thread[Thread-16,5,]
        at 
 org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:82)
        at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:506)
        at org.junit.rules.RunRules.evaluate(RunRules.java:18)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
        at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
        at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
        at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
        at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
        at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
        at 
 org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:73)
        at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:36)
        at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:37)
        at org.junit.rules.RunRules.evaluate(RunRules.java:18)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
        at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
        at 
 org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
 Caused by: org.junit.ComparisonFailure: term 0 expected:[] but was:[]
        at org.junit.Assert.assertEquals(Assert.java:125)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:144)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:551)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:49)
        at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:334)




 Build Log (for compile errors):
 [...truncated 9966 lines...]




 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org



-- 
lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-3899) Evil up MockDirectoryWrapper.checkIndexOnClose

2012-03-21 Thread Robert Muir (Created) (JIRA)

Evil up MockDirectoryWrapper.checkIndexOnClose
--

 Key: LUCENE-3899
 URL: https://issues.apache.org/jira/browse/LUCENE-3899
 Project: Lucene - Java
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 3.6, 4.0
 Attachments: LUCENE-3899.patch

MockDirectoryWrapper checks any indexes tests create on close(), if they exist.

The problem is the logic it uses to determine if an index exists could mask 
real bugs (e.g. segments file corrumption):
{code}
if (DirectoryReader.indexExists(this) {
  ...
  // evil stuff like crash()
  ...
  _TestUtil.checkIndex(this)
}
{code}

and for reference DirectoryReader.indexExists is:
{code}
try {
  new SegmentInfos().read(directory);
  return true;
} catch (IOException ioe) {
  return false;
}
{code}

So if there are segments file problems, we just silently do no checkIndex.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3899) Evil up MockDirectoryWrapper.checkIndexOnClose

2012-03-21 Thread Robert Muir (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-3899:


Attachment: LUCENE-3899.patch

attached is a patch: 

I had to disable checkIndexOnClose for 
TestBackwardsCompatibility.testUnsupportedOldIndexes (because we intentionally 
don't want to checkIndex() them, it will now fail).

I think its ready to commit.

 Evil up MockDirectoryWrapper.checkIndexOnClose
 --

 Key: LUCENE-3899
 URL: https://issues.apache.org/jira/browse/LUCENE-3899
 Project: Lucene - Java
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3899.patch


 MockDirectoryWrapper checks any indexes tests create on close(), if they 
 exist.
 The problem is the logic it uses to determine if an index exists could mask 
 real bugs (e.g. segments file corrumption):
 {code}
 if (DirectoryReader.indexExists(this) {
   ...
   // evil stuff like crash()
   ...
   _TestUtil.checkIndex(this)
 }
 {code}
 and for reference DirectoryReader.indexExists is:
 {code}
 try {
   new SegmentInfos().read(directory);
   return true;
 } catch (IOException ioe) {
   return false;
 }
 {code}
 So if there are segments file problems, we just silently do no checkIndex.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()

2012-03-21 Thread James Dyer (Reopened) (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer reopened SOLR-3260:
--


In light of the maven 3.x failure, I think I need to move some of the 
reflection calls from the 3nd try/catch to the 2nd.  This means we can ignore 2 
of the 3 exceptions instead of all 3.

For trunk, I can change this to not use reflection at all since we require a 
1.6+ jvm.  However, this can still fail if the scripting engines are not in the 
jvms so these checks need to stay in place.

 Improve exception handling / logging for ScriptTransformer.init()
 -

 Key: SOLR-3260
 URL: https://issues.apache.org/jira/browse/SOLR-3260
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-3260.patch


 This came up on the user-list.  ScriptTransformer logs the same need a =1.6 
 jre message for several problems, making debugging difficult for users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3898) possible SynonymFilter bug: hudson fail

2012-03-21 Thread Martijn van Groningen (Updated) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234384#comment-13234384
 ] 

Robert Muir commented on LUCENE-3898:
-

It definitely requires some beasting, but I found a seed:
{noformat}
ant test -Dtestcase=TestSynonymMapFilter -Dtestmethod=testRandom2 
-Dtests.seed=4960bdc955a84bcf:-3fa62ebdf7c327b2:-3a600dcf6292a436 
-Dtests.multiplier=5 -Dtests.nightly=true -Dargs=-Dfile.encoding=UTF-8
{noformat}

 possible SynonymFilter bug: hudson fail
 ---

 Key: LUCENE-3898
 URL: https://issues.apache.org/jira/browse/LUCENE-3898
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
Assignee: Michael McCandless

 See https://builds.apache.org/job/Lucene-trunk/1867/consoleText (no seed)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3896) CharTokenizer has bugs for large documents.

2012-03-21 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234397#comment-13234397
 ] 

Michael McCandless commented on LUCENE-3896:


Thanks Rob!

 CharTokenizer has bugs for large documents.
 ---

 Key: LUCENE-3896
 URL: https://issues.apache.org/jira/browse/LUCENE-3896
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
Priority: Blocker
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3896.patch, LUCENE-3896.patch, LUCENE-3896.patch


 Initially found by hudson from additional testing added in LUCENE-3894, but 
 currently not reproducable (see LUCENE-3895).
 But its easy to reproduce for a simple single-threaded case in 
 TestDuelingAnalyzers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3899) Evil up MockDirectoryWrapper.checkIndexOnClose

2012-03-21 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234400#comment-13234400
 ] 

Michael McCandless commented on LUCENE-3899:


+1

More evilness!

 Evil up MockDirectoryWrapper.checkIndexOnClose
 --

 Key: LUCENE-3899
 URL: https://issues.apache.org/jira/browse/LUCENE-3899
 Project: Lucene - Java
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3899.patch


 MockDirectoryWrapper checks any indexes tests create on close(), if they 
 exist.
 The problem is the logic it uses to determine if an index exists could mask 
 real bugs (e.g. segments file corrumption):
 {code}
 if (DirectoryReader.indexExists(this) {
   ...
   // evil stuff like crash()
   ...
   _TestUtil.checkIndex(this)
 }
 {code}
 and for reference DirectoryReader.indexExists is:
 {code}
 try {
   new SegmentInfos().read(directory);
   return true;
 } catch (IOException ioe) {
   return false;
 }
 {code}
 So if there are segments file problems, we just silently do no checkIndex.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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

[GSoC]About some general information

2012-03-21 Thread Han Jiang

Hi All,

I'm Billy, a senior undergraduate student in Peking University. I'm working
in the area of Information Retrieval and Web Mining. When going through the
idea list, I felt quite interested in the
LUCENE-3892https://issues.apache.org/jira/browse/LUCENE-3892and
LUCENE-3069 https://issues.apache.org/jira/browse/LUCENE-3069. I am very
proficient on java, and have been using lucene for about one year. I am
looking forward to make a contribution to this project.

Here, I have a few questions about lucene:

First of all,  which version of lucene shall we use as a start point? The
trunk or 3.5?
Is there any demo codes to show the idea of Codecs?
How many posting formats are supposed to be implemented, for project
LUCENE-3892 https://issues.apache.org/jira/browse/LUCENE-3892 ?
Is there any further documentation for
LUCENE-3069https://issues.apache.org/jira/browse/LUCENE-3069?

Thank you!

-- 
Han Jiang

EECS, Peking University, China
Every Effort Creates Smile

Senior Student

[jira] [Updated] (LUCENE-3778) Create a grouping convenience class


 [ 
https://issues.apache.org/jira/browse/LUCENE-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martijn van Groningen updated LUCENE-3778:
--

Attachment: LUCENE-3778.patch

Updated patch. Grouplimit and groupoffset are now parameters in the search 
methods. I think it is time to commit this.

 Create a grouping convenience class
 ---

 Key: LUCENE-3778
 URL: https://issues.apache.org/jira/browse/LUCENE-3778
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/grouping
Reporter: Martijn van Groningen
 Fix For: 4.0

 Attachments: LUCENE-3778.patch, LUCENE-3778.patch, LUCENE-3778.patch, 
 LUCENE-3778.patch


 Currently the grouping module has many collector classes with a lot of 
 different options per class. I think it would be a good idea to have a 
 GroupUtil (Or another name?) convenience class. I think this could be a 
 builder, because of the many options 
 (sort,sortWithinGroup,groupOffset,groupCount and more) and implementations 
 (term/dv/function) grouping has.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3899) Evil up MockDirectoryWrapper.checkIndexOnClose

2012-03-21 Thread Robert Muir (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-3899.
-

Resolution: Fixed

 Evil up MockDirectoryWrapper.checkIndexOnClose
 --

 Key: LUCENE-3899
 URL: https://issues.apache.org/jira/browse/LUCENE-3899
 Project: Lucene - Java
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3899.patch


 MockDirectoryWrapper checks any indexes tests create on close(), if they 
 exist.
 The problem is the logic it uses to determine if an index exists could mask 
 real bugs (e.g. segments file corrumption):
 {code}
 if (DirectoryReader.indexExists(this) {
   ...
   // evil stuff like crash()
   ...
   _TestUtil.checkIndex(this)
 }
 {code}
 and for reference DirectoryReader.indexExists is:
 {code}
 try {
   new SegmentInfos().read(directory);
   return true;
 } catch (IOException ioe) {
   return false;
 }
 {code}
 So if there are segments file problems, we just silently do no checkIndex.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3898) possible SynonymFilter bug: hudson fail

2012-03-21 Thread Michael McCandless (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless resolved LUCENE-3898.


   Resolution: Fixed
Fix Version/s: 4.0
   3.6

I think this is fixed...

 possible SynonymFilter bug: hudson fail
 ---

 Key: LUCENE-3898
 URL: https://issues.apache.org/jira/browse/LUCENE-3898
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
Assignee: Michael McCandless
 Fix For: 3.6, 4.0


 See https://builds.apache.org/job/Lucene-trunk/1867/consoleText (no seed)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2921) Make any Filters, Tokenizers and CharFilters implement MultiTermAwareComponent if they should

2012-03-21 Thread Erick Erickson (Updated) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Erick Erickson updated SOLR-2921:
-

Attachment: SOLR-2921-3x.patch

Here's a first cut at these. The tests in TestFoldingMultitermExtrasQuery are
especially weak, any help here would be extremely welcome

Basically, I stole the patterns from the associated filters and removed the
ones that failed for reasons I didn't understand. And I haven't checked the
remaining all that carefully, I have some stuff coming up for most of the rest
of today and wanted to get the first cut out in front of people.

The attached patch applies against 3x, I'll need to tweak it for trunk but
won't bother until after we finalize this.

I also haven't run the full test suite, so this patch should NOT be committed
yet.

I'm not even going to try the following, I don't even know what to expect as
proper results. If nobody steps up I'll split these out into another JIRA and
hopefully someone with the appropriate knowledge (and keyboard) can volunteer:
ArabicNormalizationFilterFactory
HindiNormalizationFilterFactory
IndicNormalizationFilterFactory
PersianNormalizationFilterFactory
ICUTransformFilterFactory

Make any Filters, Tokenizers and CharFilters implement
MultiTermAwareComponent if they should
-

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2921) Make any Filters, Tokenizers and CharFilters implement MultiTermAwareComponent if they should

[
https://issues.apache.org/jira/browse/SOLR-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234434#comment-13234434
]

Robert Muir commented on SOLR-2921:
---

{quote}
I'm not even going to try the following, I don't even know what to expect as
proper results. If nobody steps up I'll split these out into another JIRA and
hopefully someone with the appropriate knowledge (and keyboard) can volunteer:
{quote}

Just make progress with your patch and keep this issue open. I'll help with
these.

As far as the existing patch, i think the multitermtest for ICU will not work
(because the support is in a contrib module: analysis-extras).
If we want a test for that stuff i think it needs to sit under that contrib.

Make any Filters, Tokenizers and CharFilters implement
MultiTermAwareComponent if they should
-

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3778) Create a grouping convenience class

2012-03-21 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234445#comment-13234445
 ] 

Michael McCandless commented on LUCENE-3778:


+1

 Create a grouping convenience class
 ---

 Key: LUCENE-3778
 URL: https://issues.apache.org/jira/browse/LUCENE-3778
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/grouping
Reporter: Martijn van Groningen
 Fix For: 4.0

 Attachments: LUCENE-3778.patch, LUCENE-3778.patch, LUCENE-3778.patch, 
 LUCENE-3778.patch


 Currently the grouping module has many collector classes with a lot of 
 different options per class. I think it would be a good idea to have a 
 GroupUtil (Or another name?) convenience class. I think this could be a 
 builder, because of the many options 
 (sort,sortWithinGroup,groupOffset,groupCount and more) and implementations 
 (term/dv/function) grouping has.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3900) Make BaseTokenStreamTestCase.checkRandomData more debuggable

2012-03-21 Thread Robert Muir (Created) (JIRA)

Make BaseTokenStreamTestCase.checkRandomData more debuggable


 Key: LUCENE-3900
 URL: https://issues.apache.org/jira/browse/LUCENE-3900
 Project: Lucene - Java
  Issue Type: Task
Reporter: Robert Muir


This thing has gotten meaner recently, but if it fails, it can be tough to 
debug.

I feel like usually we just look at whatever analyzer failed, and completely 
review the code
and look for any smells until it passes :)

So I think instead we can possibly make this easier if this does something like:
{code}
try { 
 ...checks... 
} catch (Throwable t) { 
  BaseTokenException e = new BaseTokenException(randomInputUsed, 
randomParamter1, randomParameter2); 
  e.setInitCause(t); 
  throw e; 
}
{code}

Then you could have a useful exception with the input string that caused the 
fail,
information about whether or not charfilter/mockreaderwrapper/whatever were 
used, etc,
as well as the initial problem as root cause.




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3900) Make BaseTokenStreamTestCase.checkRandomData more debuggable

2012-03-21 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234446#comment-13234446
 ] 

Michael McCandless commented on LUCENE-3900:


+1!

 Make BaseTokenStreamTestCase.checkRandomData more debuggable
 

 Key: LUCENE-3900
 URL: https://issues.apache.org/jira/browse/LUCENE-3900
 Project: Lucene - Java
  Issue Type: Task
Reporter: Robert Muir

 This thing has gotten meaner recently, but if it fails, it can be tough to 
 debug.
 I feel like usually we just look at whatever analyzer failed, and completely 
 review the code
 and look for any smells until it passes :)
 So I think instead we can possibly make this easier if this does something 
 like:
 {code}
 try { 
  ...checks... 
 } catch (Throwable t) { 
   BaseTokenException e = new BaseTokenException(randomInputUsed, 
 randomParamter1, randomParameter2); 
   e.setInitCause(t); 
   throw e; 
 }
 {code}
 Then you could have a useful exception with the input string that caused the 
 fail,
 information about whether or not charfilter/mockreaderwrapper/whatever were 
 used, etc,
 as well as the initial problem as root cause.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()


[ 
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234451#comment-13234451
 ] 

Steven Rowe commented on SOLR-3260:
---

bq. In light of the maven 3.x failure, I think I need to move some of the 
reflection calls from the 3nd try/catch to the 2nd. This means we can ignore 2 
of the 3 exceptions instead of all 3.

+1

 Improve exception handling / logging for ScriptTransformer.init()
 -

 Key: SOLR-3260
 URL: https://issues.apache.org/jira/browse/SOLR-3260
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-3260.patch


 This came up on the user-list.  ScriptTransformer logs the same need a =1.6 
 jre message for several problems, making debugging difficult for users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()


[ 
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234449#comment-13234449
 ] 

Steven Rowe commented on SOLR-3260:
---

I see we got the same failures on the trunk Maven build today: 
https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/

I'll forward-port my test-skipping changes to trunk.

 Improve exception handling / logging for ScriptTransformer.init()
 -

 Key: SOLR-3260
 URL: https://issues.apache.org/jira/browse/SOLR-3260
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-3260.patch


 This came up on the user-list.  ScriptTransformer logs the same need a =1.6 
 jre message for several problems, making debugging difficult for users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3897) KuromojiTokenizer fails with large docs

2012-03-21 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234455#comment-13234455
 ] 

Michael McCandless commented on LUCENE-3897:


I think the problem is when we force a backtrace (if it's = 1024 chars since 
the last backtrace)... I think we are not correctly pruning all paths in this 
case.

Unlike the natural backtrace, which happens whenever there is only 1 path (ie 
the parsing is unambiguous from that point backwards), the forced backtrace may 
have more than one live path.

Have to mull how to fix...

 KuromojiTokenizer fails with large docs
 ---

 Key: LUCENE-3897
 URL: https://issues.apache.org/jira/browse/LUCENE-3897
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
 Fix For: 3.6, 4.0


 just shoving largeish random docs triggers asserts like:
 {noformat}
 [junit] Caused by: java.lang.AssertionError: backPos=4100 vs 
 lastBackTracePos=5120
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.backtrace(KuromojiTokenizer.java:907)
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.parse(KuromojiTokenizer.java:756)
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.incrementToken(KuromojiTokenizer.java:403)
 [junit]   at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:404)
 {noformat}
 But, you get no seed...
 I'll commit the test case and @Ignore it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3897) KuromojiTokenizer fails with large docs

2012-03-21 Thread Christian Moen (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234456#comment-13234456
 ] 

Christian Moen commented on LUCENE-3897:


I've been trying to make an even more isolated case that reproduces this 
problem.  I'm new to {{LuceneTestCaseRunner}} and {{checkRandomData}}, but I 
received very helpful advise on how to follow up on this.  Thanks, Robert!

I'll look further into this tomorrow.  Mike, if you have any ideas on what the 
root cause of this could be, please feel free to chime in.  Many thanks.

 KuromojiTokenizer fails with large docs
 ---

 Key: LUCENE-3897
 URL: https://issues.apache.org/jira/browse/LUCENE-3897
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
 Fix For: 3.6, 4.0


 just shoving largeish random docs triggers asserts like:
 {noformat}
 [junit] Caused by: java.lang.AssertionError: backPos=4100 vs 
 lastBackTracePos=5120
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.backtrace(KuromojiTokenizer.java:907)
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.parse(KuromojiTokenizer.java:756)
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.incrementToken(KuromojiTokenizer.java:403)
 [junit]   at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:404)
 {noformat}
 But, you get no seed...
 I'll commit the test case and @Ignore it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()

2012-03-21 Thread Ryan McKinley (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234472#comment-13234472
 ] 

Ryan McKinley commented on SOLR-3260:
-

bq. class javax.servlet.FilterRegistration's signer information does not 
match signer information of other classes in the same package

I have seen this before when servlet-2.5 and servlet-api 3.0 are both in the 
classpath

 Improve exception handling / logging for ScriptTransformer.init()
 -

 Key: SOLR-3260
 URL: https://issues.apache.org/jira/browse/SOLR-3260
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-3260.patch


 This came up on the user-list.  ScriptTransformer logs the same need a =1.6 
 jre message for several problems, making debugging difficult for users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()


[ 
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234477#comment-13234477
 ] 

Steven Rowe commented on SOLR-3260:
---

{quote}
bq. class javax.servlet.FilterRegistration's signer information does not 
match signer information of other classes in the same package

I have seen this before when servlet-2.5 and servlet-api 3.0 are both in the 
classpath
{quote}

Yeah, I'm testing a change to the solr-core POM that would make the servlet 
dependency use the provided scope, which would exclude it from the runtime 
classpath.

Seems to fix the trunk failures you're referring to in the DIH tests.  Running 
all Solr tests locally now before I commit the change.

 Improve exception handling / logging for ScriptTransformer.init()
 -

 Key: SOLR-3260
 URL: https://issues.apache.org/jira/browse/SOLR-3260
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-3260.patch


 This came up on the user-list.  ScriptTransformer logs the same need a =1.6 
 jre message for several problems, making debugging difficult for users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-tests-only-trunk-java7 - Build # 2039 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2039/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
ERROR: SolrIndexSearcher opens=94 closes=93

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=94 
closes=93
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner$3.addError(JUnitTestRunner.java:974)
at junit.framework.TestResult.addError(TestResult.java:38)
at 
junit.framework.JUnit4TestAdapterCache$1.testFailure(JUnit4TestAdapterCache.java:51)
at 
org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100)
at 
org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
at 
org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97)
at 
org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:306)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
Caused by: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=94 closes=93
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:37)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:39)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
... 4 more




Build Log (for compile errors):
[...truncated 9849 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [GSoC]About some general information

2012-03-21 Thread Michael McCandless

Hello!  Answers below...:

On Wed, Mar 21, 2012 at 11:03 AM, Han Jiang jiangha...@gmail.com wrote:
 Hi All,

 I'm Billy, a senior undergraduate student in Peking University. I'm working
 in the area of Information Retrieval and Web Mining. When going through the
 idea list, I felt quite interested in the LUCENE-3892 and LUCENE-3069. I am
 very proficient on java, and have been using lucene for about one year. I am
 looking forward to make a contribution to this project.

Awesome.

 Here, I have a few questions about lucene:

 First of all,  which version of lucene shall we use as a start point? The
 trunk or 3.5?

Both of these issues will be trunk only I think: they both are far
easier to do with the Codec API in 4.0.

 Is there any demo codes to show the idea of Codecs?

Maybe the simplest demo would be to look at the SimpleText codec?  It
roughly tries to have simple source code as well as a simple (text
only, human readable) on-disk format.

 How many posting formats are supposed to be implemented, for project
 LUCENE-3892 ?

This can be worked out when scoping the project... but I think getting
one postings format working well would be awesome :)  If somehow
that's too easy, then add more!

 Is there any further documentation for LUCENE-3069 ?

Not that I know of... but I suspect the approach can be very similar
to the MemoryPostingsFormat we already have, just that it'd only be
the terms data stored in the FST, while the postings
(docs/freqs/positions/offsets) are written to a file.

Ideally, it would just act like a different terms dictionary
implementation, ie so that we can then plug in any PostingsBaseFormat
(even the one from LUCENE-3892!).

 Thank you!

You're welcome, and welcome to Lucene/Solr!

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] [Resolved] (SOLR-3260) Improve exception handling / logging for ScriptTransformer.init()

2012-03-21 Thread James Dyer (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer resolved SOLR-3260.
--

Resolution: Fixed

Trunk: r1303470 - Removed reflection as Trunk uses JRE 1.6+.  Unit Test no 
longer ignores exceptions.

Branch_3x: r1303464 - moved things in try/catch blocks so as to be able to 
ignore 1 fewer exception (also better from a user's perspective)

Hopefully this is it!

 Improve exception handling / logging for ScriptTransformer.init()
 -

 Key: SOLR-3260
 URL: https://issues.apache.org/jira/browse/SOLR-3260
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-3260.patch


 This came up on the user-list.  ScriptTransformer logs the same need a =1.6 
 jre message for several problems, making debugging difficult for users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2788) Make CharFilter reusable

2012-03-21 Thread Michael McCandless (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234556#comment-13234556
 ] 

Michael McCandless commented on LUCENE-2788:


+1

I really like the approach here (just using FilterReader instead of our own new 
class).

Since the back-compat is going be tricky... maybe we should first commit this 
patch to trunk?

 Make CharFilter reusable
 

 Key: LUCENE-2788
 URL: https://issues.apache.org/jira/browse/LUCENE-2788
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Robert Muir
Priority: Minor
 Attachments: LUCENE-2788.patch


 The CharFilter API lets you wrap a Reader, altering the contents before the 
 Tokenizer sees them.
 It also allows you to correct the offsets so this is transparent to 
 highlighting.
 One problem is that the API isn't reusable, if you have a lot of short 
 documents its going to be efficient.
 Additionally there is some unnecessary wrapping in Tokenizer (see the 
 CharReader.get in the ctor, but *not* in reset(Reader)!!!)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2921) Make any Filters, Tokenizers and CharFilters implement MultiTermAwareComponent if they should

2012-03-21 Thread Erick Erickson (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234571#comment-13234571
]

Erick Erickson commented on SOLR-2921:
--

Hey, man, it worked from inside IntelliJ. I thought getting to the schema in
core from analysis-extras (where TestFoldingMultitermExtrasQuery lives) was
funky. I'll have a patch up for that shortly.

Make any Filters, Tokenizers and CharFilters implement
MultiTermAwareComponent if they should
-

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3897) KuromojiTokenizer fails with large docs

2012-03-21 Thread Michael McCandless (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-3897:
---

Attachment: LUCENE-3897.patch

Christian and I discusses this on IRC... and it seems like the only real course 
of action when we must force the backtrace (for safety / prevent adversary) is 
to prune all but the least cost partial path.

I implemented that approach (patch) and now this seed passes... I'll beast some 
more.

 KuromojiTokenizer fails with large docs
 ---

 Key: LUCENE-3897
 URL: https://issues.apache.org/jira/browse/LUCENE-3897
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3897.patch


 just shoving largeish random docs triggers asserts like:
 {noformat}
 [junit] Caused by: java.lang.AssertionError: backPos=4100 vs 
 lastBackTracePos=5120
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.backtrace(KuromojiTokenizer.java:907)
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.parse(KuromojiTokenizer.java:756)
 [junit]   at 
 org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.incrementToken(KuromojiTokenizer.java:403)
 [junit]   at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:404)
 {noformat}
 But, you get no seed...
 I'll commit the test case and @Ignore it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2382) DIH Cache Improvements

2012-03-21 Thread James Dyer (Reopened) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Dyer reopened SOLR-2382:
--

Assignee: James Dyer

Re-Open to backport for 3.x This is being done so that the SOLR-3011 thread
fixes can be included in 3.x. (Plan is to give 3.x users a stable-enough
threads implementation in 3.x, then remove threads from trunk.)

DIH Cache Improvements
--

Key: SOLR-2382
URL: https://issues.apache.org/jira/browse/SOLR-2382
Project: Solr
Issue Type: New Feature
Components: contrib - DataImportHandler
Reporter: James Dyer
Assignee: James Dyer
Priority: Minor
Fix For: 4.0

Attachments: SOLR-2382-dihwriter.patch, SOLR-2382-dihwriter.patch,
SOLR-2382-dihwriter.patch, SOLR-2382-dihwriter.patch,
SOLR-2382-dihwriter.patch, SOLR-2382-dihwriter_standalone.patch,
SOLR-2382-entities.patch, SOLR-2382-entities.patch, SOLR-2382-entities.patch,
SOLR-2382-entities.patch, SOLR-2382-entities.patch, SOLR-2382-entities.patch,
SOLR-2382-entities.patch, SOLR-2382-entities.patch,
SOLR-2382-properties.patch, SOLR-2382-properties.patch,
SOLR-2382-solrwriter-verbose-fix.patch, SOLR-2382-solrwriter.patch,
SOLR-2382-solrwriter.patch, SOLR-2382-solrwriter.patch, SOLR-2382.patch,
SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch,
SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch,
TestCachedSqlEntityProcessor.java-break-where-clause.patch,
TestCachedSqlEntityProcessor.java-fix-where-clause-by-adding-cachePk-and-lookup.patch,

TestCachedSqlEntityProcessor.java-wrong-pk-detected-due-to-lack-of-where-support.patch,
TestThreaded.java.patch

Functionality:
1. Provide a pluggable caching framework for DIH so that users can choose a
cache implementation that best suits their data and application.

2. Provide a means to temporarily cache a child Entity's data without
needing to create a special cached implementation of the Entity Processor
(such as CachedSqlEntityProcessor).

3. Provide a means to write the final (root entity) DIH output to a cache
rather than to Solr. Then provide a way for a subsequent DIH call to use the
cache as an Entity input. Also provide the ability to do delta updates on
such persistent caches.

4. Provide the ability to partition data across multiple caches that can
then be fed back into DIH and indexed either to varying Solr Shards, or to
the same Core in parallel.
Use Cases:
1. We needed a flexible scalable way to temporarily cache child-entity
data prior to joining to parent entities.
- Using SqlEntityProcessor with Child Entities can cause an n+1 select
problem.
- CachedSqlEntityProcessor only supports an in-memory HashMap as a Caching
mechanism and does not scale.
- There is no way to cache non-SQL inputs (ex: flat files, xml, etc).

2. We needed the ability to gather data from long-running entities by a
process that runs separate from our main indexing process.

3. We wanted the ability to do a delta import of only the entities that
changed.
- Lucene/Solr requires entire documents to be re-indexed, even if only a
few fields changed.
- Our data comes from 50+ complex sql queries and/or flat files.
- We do not want to incur overhead re-gathering all of this data if only 1
entity's data changed.
- Persistent DIH caches solve this problem.

4. We want the ability to index several documents in parallel (using 1.4.1,
which did not have the threads parameter).

5. In the future, we may need to use Shards, creating a need to easily
partition our source data into Shards.
Implementation Details:
1. De-couple EntityProcessorBase from caching.
- Created a new interface, DIHCache two implementations:
- SortedMapBackedCache - An in-memory cache, used as default with
CachedSqlEntityProcessor (now deprecated).
- BerkleyBackedCache - A disk-backed cache, dependent on bdb-je, tested
with je-4.1.6.jar
- NOTE: the existing Lucene Contrib db project uses je-3.3.93.jar.
I believe this may be incompatible due to Generic Usage.
- NOTE: I did not modify the ant script to automatically get this jar,
so to use or evaluate this patch, download bdb-je from
http://www.oracle.com/technetwork/database/berkeleydb/downloads/index.html

2. Allow Entity Processors to take a cacheImpl parameter to cause the
entity data to be cached (see EntityProcessorBase DIHCacheProperties).

3. Partially De-couple SolrWriter from DocBuilder
- Created a new interface DIHWriter, two implementations:
- SolrWriter (refactored)
- DIHCacheWriter (allows DIH to write ultimately to a Cache).

4. Create a new Entity Processor, DIHCacheProcessor, which reads a
persistent Cache as DIH Entity

[jira] [Updated] (SOLR-2382) DIH Cache Improvements

2012-03-21 Thread James Dyer (Updated) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Dyer updated SOLR-2382:
-

Fix Version/s: 3.6

DIH Cache Improvements
--

TestCachedSqlEntityProcessor.java-wrong-pk-detected-due-to-lack-of-where-support.patch,
TestThreaded.java.patch

Functionality:
1. Provide a pluggable caching framework for DIH so that users can choose a
cache implementation that best suits their data and application.

2. Provide a means to temporarily cache a child Entity's data without
needing to create a special cached implementation of the Entity Processor
(such as CachedSqlEntityProcessor).

2. We needed the ability to gather data from long-running entities by a
process that runs separate from our main indexing process.

4. We want the ability to index several documents in parallel (using 1.4.1,
which did not have the threads parameter).

2. Allow Entity Processors to take a cacheImpl parameter to cause the
entity data to be cached (see EntityProcessorBase DIHCacheProperties).

3. Partially De-couple SolrWriter from DocBuilder
- Created a new interface DIHWriter, two implementations:
- SolrWriter (refactored)
- DIHCacheWriter (allows DIH to write ultimately to a Cache).

4. Create a new Entity Processor, DIHCacheProcessor, which reads a
persistent Cache as DIH Entity Input.

5. Support a partition parameter with both DIHCacheWriter and
DIHCacheProcessor to allow for easy partitioning of source entity data.

6. Change the semantics of entity.destroy()
- Previously, it was being called

[jira] [Updated] (SOLR-3011) DIH MultiThreaded bug

2012-03-21 Thread James Dyer (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer updated SOLR-3011:
-

Affects Version/s: (was: 4.0)
Fix Version/s: (was: 4.0)
   3.6

Changing fix version for 3.6.  For trunk, I would like to remove the threads 
feature.

 DIH MultiThreaded bug
 -

 Key: SOLR-3011
 URL: https://issues.apache.org/jira/browse/SOLR-3011
 Project: Solr
  Issue Type: Sub-task
  Components: contrib - DataImportHandler
Affects Versions: 3.5
Reporter: Mikhail Khludnev
Priority: Minor
 Fix For: 3.6

 Attachments: SOLR-3011.patch, SOLR-3011.patch, SOLR-3011.patch, 
 SOLR-3011.patch, patch-3011-EntityProcessorBase-iterator.patch, 
 patch-3011-EntityProcessorBase-iterator.patch


 current DIH design is not thread safe. see last comments at SOLR-2382 and 
 SOLR-2947. I'm going to provide the patch makes DIH core threadsafe. Mostly 
 it's a SOLR-2947 patch from 28th Dec. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3074) SolrPluginUtils.docListToSolrDocumentList is broken, existing test is also broken

2012-03-21 Thread Ryan McKinley (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234814#comment-13234814
 ] 

Ryan McKinley commented on SOLR-3074:
-

bq. remove these methods in trunk

+1


I *think* this was used long ago before the javabin format took over 
serializing DocList 

 SolrPluginUtils.docListToSolrDocumentList is broken, existing test is also 
 broken
 -

 Key: SOLR-3074
 URL: https://issues.apache.org/jira/browse/SOLR-3074
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 3.5
Reporter: Ahmet Arslan
Assignee: Hoss Man
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: SOLR-3074.patch, SOLR-3074.patch


 testDocListConversion() is not testing what it's suppossed to test. Because 
 added test documents are not committed.
 http://search-lucene.com/m/uwh9l2SHH4e

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3262) Remove threads from DIH (Trunk only)

2012-03-21 Thread James Dyer (Created) (JIRA)

Remove threads from DIH (Trunk only)
--

 Key: SOLR-3262
 URL: https://issues.apache.org/jira/browse/SOLR-3262
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Minor
 Fix For: 4.0


SOLR-1352 introduced a multi-threading feature for DataImportHandler.  
Historically, this feature only seemed to work in a limited set of cases and I 
don't think we can guarantee users that using threads will behave 
consistently.  Also, the multi-threaded option adds considerable complexity 
making code refactoring difficult. 

I propose removing threads from Trunk.  (But keep it in 3.x, applying any bug 
fixes for it there.)  This can be a first step in improving the DIH code base.  

Eventually we can possibly add a carefully though-out threads implementation 
back in.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: First pass pruning 3.6 Jira's to ramp up for release

2012-03-21 Thread Chris Hostetter


: I volunteer to do the first bulk fix!=3.6 pruning against The Query in a
: few days (wed or thurs) if no one objects in the meantime.

: The Query
: (unresolved, fix=3.6, no assignee, updatedDate  march  not bug)
: 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+fixVersion+%3D+%223.6%22+AND+resolution+%3D+Unresolved+AND+assignee+is+EMPTY+AND+updatedDate+%3C+2012-03-01+AND+issuetype+!%3D+Bug

I've moved forward on this, bulk editing the (156) issues currently 
matching that criteria to remove the 3.6 fix version (and suppressing emial 
notification to reduce noise)

You can identify all the issues modified by this bulk edit by searching 
jira comments for hoss20120321nofix36

(note: aparently jira doesn't have a way to just remove a fix version - i 
could have sworn it did - so i had to just replace the fix version for 
these issues with 4.0)

Next up: prune, Prune, PRUNE

Unless I hear objections, i think that ~48 hours from now we should bite 
the bullet and prune any unassigned issue (regardless of type) that hasn't 
been updated since March 19 (ie: actively being discussed 
this week)...

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+fixVersion+%3D+%223.6%22+AND+resolution+%3D+Unresolved+AND+assignee+is+EMPTY+AND+updatedDate+%3C+2012-03-19

...that will get us to the point where almost all of the outstanding 3.6 
issues are assigned to someone, and we can start harping on people 
individually where are you with this issue?

As a reminder, here are the folks who currently have open 3.6 issues 
assigned to them...

1  Adriano Crestani
1  Andrzej Bialecki
2  David Smiley
1  Doron Cohen
1  Erik Hatcher
1  Grant Ingersoll
2  Hoss Man
1  James Dyer
3  Jan Høydahl
1  Koji Sekiguchi
11 Mark Miller
17 Noble Paul
4 Shalin Shekhar Mangar
3 Simon Willnauer
2 Stanislaw Osinski
2 Tommaso Teofili
3 Uwe Schindler


If you are logged into Jira you can see the 3.6 issues assigned to you 
here...

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+in+%28SOLR%2C+LUCENE%29+AND+fixV
ersion+%3D+%223.6%22+AND+resolution+%3D+Unresolved+AND+assignee+%3D+currentUser%28%29





-Hoss

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2921) Make any Filters, Tokenizers and CharFilters implement MultiTermAwareComponent if they should

2012-03-21 Thread Erick Erickson (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-2921:
-

Attachment: SOLR-2921-3x.patch

Fixes test cases in analysis-extras so it runs from the command line not only 
in IntelliJ.

 Make any Filters, Tokenizers and CharFilters implement 
 MultiTermAwareComponent if they should
 -

 Key: SOLR-2921
 URL: https://issues.apache.org/jira/browse/SOLR-2921
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Affects Versions: 3.6, 4.0
 Environment: All
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-2921-3x.patch, SOLR-2921-3x.patch


 SOLR-2438 creates a new MultiTermAwareComponent interface. This allows Solr 
 to automatically assemble a multiterm analyzer that does the right thing 
 vis-a-vis transforming the individual terms of a multi-term query at query 
 time. Examples are: lower casing, folding accents, etc. Currently 
 (27-Nov-2011), the following classes implement MultiTermAwareComponent:
  * ASCIIFoldingFilterFactory
  * LowerCaseFilterFactory
  * LowerCaseTokenizerFactory
  * MappingCharFilterFactory
  * PersianCharFilterFactory
 When users put any of the above in their query analyzer, Solr will do the 
 right thing at query time and the perennial question users have, why didn't 
 my wildcard query automatically lower-case (or accent fold or) my terms? 
 will be gone. Die question die!
 But taking a quick look, for instance, at the various FilterFactories that 
 exist, there are a number of possibilities that *might* be good candidates 
 for implementing MultiTermAwareComponent. But I really don't understand the 
 correct behavior here well enough to know whether these should implement the 
 interface or not. And this doesn't include other CharFilters or Tokenizers.
 Actually implementing the interface is often trivial, see the classes above 
 for examples. Note that LowerCaseTokenizerFactory returns a *Filter*, which 
 is the right thing in this case.
 Here is a quick cull of the Filters that, just from their names, might be 
 candidates. If anyone wants to take any of them on, that would be great. If 
 all you can do is provide test cases, I could probably do the code part, just 
 let me know.
 ArabicNormalizationFilterFactory
 GreekLowerCaseFilterFactory
 HindiNormalizationFilterFactory
 ICUFoldingFilterFactory
 ICUNormalizer2FilterFactory
 ICUTransformFilterFactory
 IndicNormalizationFilterFactory
 ISOLatin1AccentFilterFactory
 PersianNormalizationFilterFactory
 RussianLowerCaseFilterFactory
 TurkishLowerCaseFilterFactory

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3263) Stop including more than one servlet-api jar version in the test classpath in the Maven build

2012-03-21 Thread Steven Rowe (Created) (JIRA)

Stop including more than one servlet-api jar version in the test classpath in 
the Maven build
-

 Key: SOLR-3263
 URL: https://issues.apache.org/jira/browse/SOLR-3263
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe


[Today's nightly Jenkins Maven trunk 
build|https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/] 
has several test failures with the error message:

{noformat}
class javax.servlet.FilterRegistration's signer information does not match 
signer information of other classes in the same package
{noformat}

On SOLR-3260, [Ryan McKinley 
mentioned|https://issues.apache.org/jira/browse/SOLR-3260?focusedCommentId=13234472page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13234472]
 that these errors can be caused by mixing servlet-api jar versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()


[ 
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234854#comment-13234854
 ] 

Steven Rowe commented on SOLR-3260:
---

{quote}
  class javax.servlet.FilterRegistration's signer information does not
  match signer information of other classes in the same package

 I have seen this before when servlet-2.5 and servlet-api 3.0 are both in the 
 classpath

Yeah, I'm testing a change to the solr-core POM that would make the servlet 
dependency use the provided scope, which would exclude it from the runtime 
classpath.

Seems to fix the trunk failures you're referring to in the DIH tests. Running 
all Solr tests locally now before I commit the change.
{quote}

See SOLR-3263

 Improve exception handling / logging for ScriptTransformer.init()
 -

 Key: SOLR-3260
 URL: https://issues.apache.org/jira/browse/SOLR-3260
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Assignee: James Dyer
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-3260.patch


 This came up on the user-list.  ScriptTransformer logs the same need a =1.6 
 jre message for several problems, making debugging difficult for users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2921) Make any Filters, Tokenizers and CharFilters implement MultiTermAwareComponent if they should


[ 
https://issues.apache.org/jira/browse/SOLR-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234855#comment-13234855
 ] 

Robert Muir commented on SOLR-2921:
---

Patch looks good: i think you should commit it and I'll follow up with the 
other ones.

only one nitpick:
{noformat}
-/** 
+/**
  * Factory for {@link TurkishLowerCaseFilter}.
  * pre class=prettyprint 
  * lt;fieldType name=text_trlwr class=solr.TextField 
positionIncrementGap=100gt;
- *   lt;analyzergt;
- * lt;tokenizer class=solr.StandardTokenizerFactory/gt;
- * lt;filter class=solr.TurkishLowerCaseFilterFactory/gt;
- *   lt;/analyzergt;
- * lt;/fieldTypegt;/pre 
+ * lt;analyzergt;
+ * lt;tokenizer class=solr.StandardTokenizerFactory/gt;
+ * lt;filter class=solr.TurkishLowerCaseFilterFactory/gt;
+ * lt;/analyzergt;
+ * lt;/fieldTypegt;/pre
+ *
{noformat}

Did your IDE do this? I don't think we should lose the indentation of the 
example there.


 Make any Filters, Tokenizers and CharFilters implement 
 MultiTermAwareComponent if they should
 -

 Key: SOLR-2921
 URL: https://issues.apache.org/jira/browse/SOLR-2921
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Affects Versions: 3.6, 4.0
 Environment: All
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-2921-3x.patch, SOLR-2921-3x.patch


 SOLR-2438 creates a new MultiTermAwareComponent interface. This allows Solr 
 to automatically assemble a multiterm analyzer that does the right thing 
 vis-a-vis transforming the individual terms of a multi-term query at query 
 time. Examples are: lower casing, folding accents, etc. Currently 
 (27-Nov-2011), the following classes implement MultiTermAwareComponent:
  * ASCIIFoldingFilterFactory
  * LowerCaseFilterFactory
  * LowerCaseTokenizerFactory
  * MappingCharFilterFactory
  * PersianCharFilterFactory
 When users put any of the above in their query analyzer, Solr will do the 
 right thing at query time and the perennial question users have, why didn't 
 my wildcard query automatically lower-case (or accent fold or) my terms? 
 will be gone. Die question die!
 But taking a quick look, for instance, at the various FilterFactories that 
 exist, there are a number of possibilities that *might* be good candidates 
 for implementing MultiTermAwareComponent. But I really don't understand the 
 correct behavior here well enough to know whether these should implement the 
 interface or not. And this doesn't include other CharFilters or Tokenizers.
 Actually implementing the interface is often trivial, see the classes above 
 for examples. Note that LowerCaseTokenizerFactory returns a *Filter*, which 
 is the right thing in this case.
 Here is a quick cull of the Filters that, just from their names, might be 
 candidates. If anyone wants to take any of them on, that would be great. If 
 all you can do is provide test cases, I could probably do the code part, just 
 let me know.
 ArabicNormalizationFilterFactory
 GreekLowerCaseFilterFactory
 HindiNormalizationFilterFactory
 ICUFoldingFilterFactory
 ICUNormalizer2FilterFactory
 ICUTransformFilterFactory
 IndicNormalizationFilterFactory
 ISOLatin1AccentFilterFactory
 PersianNormalizationFilterFactory
 RussianLowerCaseFilterFactory
 TurkishLowerCaseFilterFactory

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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

Intermittent testing errors in TestSystemPropertiesInvariantRule

2012-03-21 Thread Erick Erickson

I'm rather consistently getting errors when I run ant clean test on
Solr 3.x. Not saying that these area NOT on trunk, but I'm on 3.x at
the moment.

e.g.

ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod2
-Dtests.seed=-3b454f200cdffb4d:4d3124ee9a92369a:286699633a5841fc
-Dargs=-Dfile.encoding=MacRoman

ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod1
-Dtests.seed=-3b454f200cdffb4d:-79099c4209c2611d:286699633a5841fc
-Dargs=-Dfile.encoding=MacRoman

ant test -Dtestcase=NonStringProperties -Dtestmethod=testMethod1
-Dtests.seed=416ce6ff0a0c890b:5ca9698c9bf42fa1:286699633a5841fc
-Dargs=-Dfile.encoding=MacRoman


in TestSystemPropertiesInvariantRule

Of course, they run fine when I run them individually. They run fine
when I run them in IntelliJ. I'm running in the java 1.5, on OS X,
took the code around 10:00 EDT 21-Mar.


Is anyone else seeing this locally? I'm tempted to ignore it in terms
of JIRAs I'm working on because it seems unlikely to be related to
them.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-2788) Make CharFilter reusable


[ 
https://issues.apache.org/jira/browse/LUCENE-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234860#comment-13234860
 ] 

Robert Muir commented on LUCENE-2788:
-

The patch likely needs to be brought up to speed (probably not too bad, but 
maybe some work).

I'm gonna be focused on 3.6 for a while, so if anyone wants to take this, feel 
free!

 Make CharFilter reusable
 

 Key: LUCENE-2788
 URL: https://issues.apache.org/jira/browse/LUCENE-2788
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Robert Muir
Priority: Minor
 Attachments: LUCENE-2788.patch


 The CharFilter API lets you wrap a Reader, altering the contents before the 
 Tokenizer sees them.
 It also allows you to correct the offsets so this is transparent to 
 highlighting.
 One problem is that the API isn't reusable, if you have a lot of short 
 documents its going to be efficient.
 Additionally there is some unnecessary wrapping in Tokenizer (see the 
 CharReader.get in the ctor, but *not* in reset(Reader)!!!)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3221) Make Shard handler threadpool configurable

2012-03-21 Thread Greg Bowyer (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234862#comment-13234862
 ] 

Greg Bowyer commented on SOLR-3221:
---

I added some information to the wiki in the solrconfig.xml section talking 
about the shardHandlerFactory that you might want to review. Documentation is 
not my strong point

also can we can put the following into the CHANGES.TXT

* SOLR-3221: Added the ability to directly configure aspects of the concurrency
  and thread-pooling used within distributed search in solr. This allows for 
finer
  grained controlled and can be tuned by end users to target their own specific
  requirements. This builds on the work of the HttpCommComponent and uses the 
same
  configuration block to configure the thread pool. The default configuration 
has
  the same behaviour as solr 3.5, favouring throughput over latency. More
  information can be found on the wiki 
(http://wiki.apache.org/solr/SolrConfigXml)

 Make Shard handler threadpool configurable
 --

 Key: SOLR-3221
 URL: https://issues.apache.org/jira/browse/SOLR-3221
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.6, 4.0
Reporter: Greg Bowyer
Assignee: Erick Erickson
  Labels: distributed, http, shard
 Fix For: 3.6, 4.0

 Attachments: SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, 
 SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch


 From profiling of monitor contention, as well as observations of the
 95th and 99th response times for nodes that perform distributed search
 (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code
 currently does a suboptimal job of managing outgoing shard level
 requests.
 Presently the code contained within lucene 3.5's SearchHandler and
 Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in
 order to service distributed search requests. This is done presently to
 limit the size of the threadpool such that it does not consume resources
 in deployment configurations that do not use distributed search.
 This unfortunately has two impacts on the response time if the node
 coordinating the distribution is under high load.
 The usage of the MaxConnectionsPerHost configuration option results in
 aggressive activity on semaphores within HttpCommons, it has been
 observed that the aggregator can have a response time far greater than
 that of the searchers. The above monitor contention would appear to
 suggest that in some cases its possible for liveness issues to occur and
 for simple queries to be starved of resources simply due to a lack of
 attention from the viewpoint of context switching.
 With, as mentioned above the http commons connection being hotly
 contended
 The fair, queue based configuration eliminates this, at the cost of
 throughput.
 This patch aims to make the threadpool largely configurable allowing for
 those using solr to choose the throughput vs latency balance they
 desire.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: Intermittent testing errors in TestSystemPropertiesInvariantRule

2012-03-21 Thread Steven Rowe (Issue Comment Edited) (JIRA)

Hi Erick,

These are not build-failing errors, are they? What you're seeing on
the console  is most likely what's a side effect of running these test
suites as part of another test; the way it works is I have some suites
that test the testing framework itself so they launch another suite
(nested class typically) _as part of the test_. Sometimes these nested
suites cause exceptions or errors on purpose and this is what you see
on the console.

I suppressed System.out's on some suites but didn't have the time to
clean it up for all of them yet. I'll take a look.

Dawid

On Wed, Mar 21, 2012 at 7:56 PM, Erick Erickson erickerick...@gmail.com wrote:
 I'm rather consistently getting errors when I run ant clean test on
 Solr 3.x. Not saying that these area NOT on trunk, but I'm on 3.x at
 the moment.

 e.g.

 ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod2
 -Dtests.seed=-3b454f200cdffb4d:4d3124ee9a92369a:286699633a5841fc
 -Dargs=-Dfile.encoding=MacRoman

 ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod1
 -Dtests.seed=-3b454f200cdffb4d:-79099c4209c2611d:286699633a5841fc
 -Dargs=-Dfile.encoding=MacRoman

 ant test -Dtestcase=NonStringProperties -Dtestmethod=testMethod1
 -Dtests.seed=416ce6ff0a0c890b:5ca9698c9bf42fa1:286699633a5841fc
 -Dargs=-Dfile.encoding=MacRoman


 in TestSystemPropertiesInvariantRule

 Of course, they run fine when I run them individually. They run fine
 when I run them in IntelliJ. I'm running in the java 1.5, on OS X,
 took the code around 10:00 EDT 21-Mar.


 Is anyone else seeing this locally? I'm tempted to ignore it in terms
 of JIRAs I'm working on because it seems unlikely to be related to
 them.

 -
 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-2382) DIH Cache Improvements

2012-03-21 Thread James Dyer (Updated) (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Dyer updated SOLR-2382:
-

Attachment: SOLR-2382_3x.patch

Patch for 3.x includes everything already committed to Trunk as well as various
bug fixes (also in Trunk already). (Patch is here for reference only ; changes
were actually moved using svn merge)

I will commit to 3.x shortly.

DIH Cache Improvements
--

Attachments: SOLR-2382-dihwriter.patch, SOLR-2382-dihwriter.patch,
SOLR-2382-dihwriter.patch, SOLR-2382-dihwriter.patch,
SOLR-2382-dihwriter.patch, SOLR-2382-dihwriter_standalone.patch,
SOLR-2382-entities.patch, SOLR-2382-entities.patch, SOLR-2382-entities.patch,
SOLR-2382-entities.patch, SOLR-2382-entities.patch, SOLR-2382-entities.patch,
SOLR-2382-entities.patch, SOLR-2382-entities.patch,
SOLR-2382-properties.patch, SOLR-2382-properties.patch,
SOLR-2382-solrwriter-verbose-fix.patch, SOLR-2382-solrwriter.patch,
SOLR-2382-solrwriter.patch, SOLR-2382-solrwriter.patch, SOLR-2382.patch,
SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch,
SOLR-2382.patch, SOLR-2382.patch, SOLR-2382.patch, SOLR-2382_3x.patch,
TestCachedSqlEntityProcessor.java-break-where-clause.patch,
TestCachedSqlEntityProcessor.java-fix-where-clause-by-adding-cachePk-and-lookup.patch,

TestCachedSqlEntityProcessor.java-wrong-pk-detected-due-to-lack-of-where-support.patch,
TestThreaded.java.patch

Functionality:
1. Provide a pluggable caching framework for DIH so that users can choose a
cache implementation that best suits their data and application.

2. Provide a means to temporarily cache a child Entity's data without
needing to create a special cached implementation of the Entity Processor
(such as CachedSqlEntityProcessor).

2. We needed the ability to gather data from long-running entities by a
process that runs separate from our main indexing process.

4. We want the ability to index several documents in parallel (using 1.4.1,
which did not have the threads parameter).

2. Allow Entity Processors to take a cacheImpl parameter to cause the
entity data to be cached (see EntityProcessorBase DIHCacheProperties).

3. Partially De-couple SolrWriter from DocBuilder
- Created a new interface DIHWriter, two implementations:
- SolrWriter (refactored)
- DIHCacheWriter (allows DIH to write ultimately to a Cache).

4. Create a new Entity Processor, DIHCacheProcessor, which

[jira] [Commented] (LUCENE-3877) Lucene should not call System.out.println

2012-03-21 Thread Dawid Weiss (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234881#comment-13234881
 ] 

Dawid Weiss commented on LUCENE-3877:
-

You can just as well substitute your own implementation of PrintStream using 
System.setOut/setErr and check stacks on printlns... But I agree with Benson 
that a static analysis approach is much cleaner. Don't know if there's anything 
out of the box in findbugs/ pmd, but even if not then this can be done as a 
10-liner by applying an aspect to classes via aspectj and parsing the output 
logs detecting if an aspect has been applied (it shouldn't match anywhere). 

 Lucene should not call System.out.println
 -

 Key: LUCENE-3877
 URL: https://issues.apache.org/jira/browse/LUCENE-3877
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 3.6, 4.0

 Attachments: IllegalSystemTest.java, IllegalSystemTest.java


 We seem to have accumulated a few random sops...
 Eg, PairOutputs.java (oal.util.fst) and MultiDocValues.java, at least.
 Can we somehow detect (eg, have a test failure) if we accidentally leave 
 errant System.out.println's (leftover from debugging)...?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3263) Stop including more than one servlet-api jar version in the test classpath in the Maven build

2012-03-21 Thread Steven Rowe (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Rowe updated SOLR-3263:
--

Attachment: SOLR-3263.patch

Patch switching the solr-core module's servlet-api dependency from compile to 
provided scope.  This causes it to not be placed on the runtime classpath.

Because this change makes most Solr contrib modules' tests fail because of 
missing classes contained in the servlet-api jar.  For those modules with 
failing tests, I added a servlet-api test dependency.

All trunk Solr tests pass for me locally under Maven.

Committing shortly.

 Stop including more than one servlet-api jar version in the test classpath in 
 the Maven build
 -

 Key: SOLR-3263
 URL: https://issues.apache.org/jira/browse/SOLR-3263
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
 Attachments: SOLR-3263.patch


 [Today's nightly Jenkins Maven trunk 
 build|https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/] 
 has several test failures with the error message:
 {noformat}
 class javax.servlet.FilterRegistration's signer information does not match 
 signer information of other classes in the same package
 {noformat}
 On SOLR-3260, [Ryan McKinley 
 mentioned|https://issues.apache.org/jira/browse/SOLR-3260?focusedCommentId=13234472page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13234472]
  that these errors can be caused by mixing servlet-api jar versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (SOLR-3263) Stop including more than one servlet-api jar version in the test classpath in the Maven build

[
https://issues.apache.org/jira/browse/SOLR-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234889#comment-13234889
]

Steven Rowe edited comment on SOLR-3263 at 3/21/12 7:10 PM:

Patch switching the solr-core module's servlet-api dependency from compile to
provided scope. This causes it to not be placed on the runtime classpath.

This change makes most Solr contrib modules' tests fail because of missing
classes contained in the servlet-api jar. For those modules with failing
tests, I added a servlet-api test dependency.

All trunk Solr tests pass for me locally under Maven.

Committing shortly.

was (Author: steve_rowe):
Patch switching the solr-core module's servlet-api dependency from
compile to provided scope. This causes it to not be placed on the runtime
classpath.

Because this change makes most Solr contrib modules' tests fail because of
missing classes contained in the servlet-api jar. For those modules with
failing tests, I added a servlet-api test dependency.

All trunk Solr tests pass for me locally under Maven.

Committing shortly.

Stop including more than one servlet-api jar version in the test classpath in
the Maven build
-

Key: SOLR-3263
URL: https://issues.apache.org/jira/browse/SOLR-3263
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
Attachments: SOLR-3263.patch

[Today's nightly Jenkins Maven trunk
build|https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/]
has several test failures with the error message:
{noformat}
class javax.servlet.FilterRegistration's signer information does not match
signer information of other classes in the same package
{noformat}
On SOLR-3260, [Ryan McKinley
mentioned|https://issues.apache.org/jira/browse/SOLR-3260?focusedCommentId=13234472page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13234472]
that these errors can be caused by mixing servlet-api jar versions.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Documents indexes

2012-03-21 Thread massimo

Hi, sorry I want to know a java method or a procedure to load some indexes of
documents already created in a directory on the desktop. I saw a method
named FSDirectoty but I don't know how it works! I proceeded in this way,
but the compiler returns an NaN (Not a Number) Exception... what I did I do
wrong? This is the sorce code I wrote, please look at it. Thank you very
much and sorry for my english, I'm italian! 


package it.unibas.ricerca.controllo;


import java.awt.event.ActionEvent;
import java.awt.event.KeyEvent;
import java.io.File;
import java.io.IOException;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.AbstractAction;
import javax.swing.KeyStroke;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.index.CorruptIndexException;
import org.apache.lucene.queryParser.ParseException;
import org.apache.lucene.queryParser.QueryParser;
import org.apache.lucene.search.IndexSearcher;
import org.apache.lucene.search.Query;
import org.apache.lucene.search.ScoreDoc;
import org.apache.lucene.search.Similarity;
import org.apache.lucene.search.TopDocs;
import org.apache.lucene.store.Directory;
import org.apache.lucene.store.FSDirectory;
import org.apache.lucene.util.Version;

//RICERCA

public class AzioneCerca2 extends AbstractAction{

private Controllo controllo;
private Similarity similarity;
private File file_for_index;
   
public AzioneCerca2(Controllo controllo){
this.controllo=controllo;
this.putValue(NAME, search file);
this.putValue(SHORT_DESCRIPTION, RICERCA DI DOCUMENTI);
this.putValue(MNEMONIC_KEY, new Integer(KeyEvent.VK_A));
this.putValue(ACCELERATOR_KEY, KeyStroke.getKeyStroke(ctrl A)); //
o alt A
}


private static final int MAX_HITS = 10;
private static final String FIELD = frase;


public void actionPerformed(ActionEvent e) {

// Effettua le inizializzazioni...
Analyzer analyzer = new MyAnalyzer();
Directory directory = null;
try {
   directory = FSDirectory.open(new
File(../../indici/index_Scenari_usecases));
} catch (IOException ex) {
Logger.getLogger(AzioneCerca2.class.getName()).log(Level.SEVERE,
null, ex);
}
try {
effettuaRicerca(Inserimento anagrafica laboratorio, MAX_HITS,
analyzer, directory);
} catch (ParseException ex) {
Logger.getLogger(AzioneCerca2.class.getName()).log(Level.SEVERE,
null, ex);
} catch (CorruptIndexException ex) {
Logger.getLogger(AzioneCerca2.class.getName()).log(Level.SEVERE,
null, ex);
} catch (IOException ex) {
Logger.getLogger(AzioneCerca2.class.getName()).log(Level.SEVERE,
null, ex);
}
}



private static void effettuaRicerca(String queryString, int maxHits,
Analyzer analyzer, Directory directory) throws ParseException,
CorruptIndexException, IOException,
org.apache.lucene.queryParser.ParseException {
// Crea la QUERY...
QueryParser parser = new QueryParser(Version.LUCENE_34, FIELD, 
analyzer);
Query query = parser.parse(queryString);

// ...la esegue...
IndexSearcher indexSearcher = new IndexSearcher(directory);
TopDocs results = indexSearcher.search(query, maxHits);
System.out.println(\nSearching ' + queryString + '.);
System.out.println(Found # + results.totalHits +  items ( +
results.getMaxScore() + ));

// ...e, infine, stampa i risultati.
ScoreDoc[] hits = results.scoreDocs;
for (int i = 0; i  hits.length; i++) {
Document hitDocIS = indexSearcher.doc(hits[i].doc);
String foundSentence = hitDocIS.get(FIELD);

System.out.println(hits[i].doc + # ( + hits[i].score + ) -  +
foundSentence);
}
indexSearcher.close();
}

}

   


--
View this message in context: 
http://lucene.472066.n3.nabble.com/Documents-indexes-tp3846328p3846328.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-3263) Stop including more than one servlet-api jar version in the test classpath in the Maven build


[ 
https://issues.apache.org/jira/browse/SOLR-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234910#comment-13234910
 ] 

Steven Rowe commented on SOLR-3263:
---

I committed to trunk.

I'll go kick off a trunk Maven build on Jenkins now.

 Stop including more than one servlet-api jar version in the test classpath in 
 the Maven build
 -

 Key: SOLR-3263
 URL: https://issues.apache.org/jira/browse/SOLR-3263
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
 Attachments: SOLR-3263.patch


 [Today's nightly Jenkins Maven trunk 
 build|https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/] 
 has several test failures with the error message:
 {noformat}
 class javax.servlet.FilterRegistration's signer information does not match 
 signer information of other classes in the same package
 {noformat}
 On SOLR-3260, [Ryan McKinley 
 mentioned|https://issues.apache.org/jira/browse/SOLR-3260?focusedCommentId=13234472page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13234472]
  that these errors can be caused by mixing servlet-api jar versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: First pass pruning 3.6 Jira's to ramp up for release

On Wed, Mar 21, 2012 at 2:38 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:

 Unless I hear objections, i think that ~48 hours from now we should bite
 the bullet and prune any unassigned issue (regardless of type) that hasn't
 been updated since March 19 (ie: actively being discussed
 this week)...


+1

-- 
lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Intermittent testing errors in TestSystemPropertiesInvariantRule

2012-03-21 Thread Erick Erickson

These are build-failing errors as far as I can tell. My touch-stone is
that I get
BUILD FAILED  at the end of the run...

On Wed, Mar 21, 2012 at 3:03 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 Hi Erick,

 These are not build-failing errors, are they? What you're seeing on
 the console  is most likely what's a side effect of running these test
 suites as part of another test; the way it works is I have some suites
 that test the testing framework itself so they launch another suite
 (nested class typically) _as part of the test_. Sometimes these nested
 suites cause exceptions or errors on purpose and this is what you see
 on the console.

 I suppressed System.out's on some suites but didn't have the time to
 clean it up for all of them yet. I'll take a look.

 Dawid

 On Wed, Mar 21, 2012 at 7:56 PM, Erick Erickson erickerick...@gmail.com 
 wrote:
 I'm rather consistently getting errors when I run ant clean test on
 Solr 3.x. Not saying that these area NOT on trunk, but I'm on 3.x at
 the moment.

 e.g.

 ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod2
 -Dtests.seed=-3b454f200cdffb4d:4d3124ee9a92369a:286699633a5841fc
 -Dargs=-Dfile.encoding=MacRoman

 ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod1
 -Dtests.seed=-3b454f200cdffb4d:-79099c4209c2611d:286699633a5841fc
 -Dargs=-Dfile.encoding=MacRoman

 ant test -Dtestcase=NonStringProperties -Dtestmethod=testMethod1
 -Dtests.seed=416ce6ff0a0c890b:5ca9698c9bf42fa1:286699633a5841fc
 -Dargs=-Dfile.encoding=MacRoman


 in TestSystemPropertiesInvariantRule

 Of course, they run fine when I run them individually. They run fine
 when I run them in IntelliJ. I'm running in the java 1.5, on OS X,
 took the code around 10:00 EDT 21-Mar.


 Is anyone else seeing this locally? I'm tempted to ignore it in terms
 of JIRAs I'm working on because it seems unlikely to be related to
 them.

 -
 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: First pass pruning 3.6 Jira's to ramp up for release

2012-03-21 Thread Uwe Schindler

+1, I will review my issues...

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


 -Original Message-
 From: Robert Muir [mailto:rcm...@gmail.com]
 Sent: Wednesday, March 21, 2012 8:41 PM
 To: dev@lucene.apache.org
 Subject: Re: First pass pruning 3.6 Jira's to ramp up for release
 
 On Wed, Mar 21, 2012 at 2:38 PM, Chris Hostetter
 hossman_luc...@fucit.org wrote:
 
  Unless I hear objections, i think that ~48 hours from now we should
  bite the bullet and prune any unassigned issue (regardless of type)
  that hasn't been updated since March 19 (ie: actively being discussed
  this week)...
 
 
 +1
 
 --
 lucidimagination.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: Intermittent testing errors in TestSystemPropertiesInvariantRule

2012-03-21 Thread Uwe Schindler

Those in TestSystemPropertiesInvariantRule don't fail the build. Maybe
another test failed before? The lengthly test output always shows up on
Jenkins! (both 3.x and trunk)

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


 -Original Message-
 From: Erick Erickson [mailto:erickerick...@gmail.com]
 Sent: Wednesday, March 21, 2012 8:48 PM
 To: dev@lucene.apache.org
 Subject: Re: Intermittent testing errors in
TestSystemPropertiesInvariantRule
 
 These are build-failing errors as far as I can tell. My touch-stone is
that I get
 BUILD FAILED  at the end of the run...
 
 On Wed, Mar 21, 2012 at 3:03 PM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
  Hi Erick,
 
  These are not build-failing errors, are they? What you're seeing on
  the console  is most likely what's a side effect of running these test
  suites as part of another test; the way it works is I have some suites
  that test the testing framework itself so they launch another suite
  (nested class typically) _as part of the test_. Sometimes these nested
  suites cause exceptions or errors on purpose and this is what you see
  on the console.
 
  I suppressed System.out's on some suites but didn't have the time to
  clean it up for all of them yet. I'll take a look.
 
  Dawid
 
  On Wed, Mar 21, 2012 at 7:56 PM, Erick Erickson
 erickerick...@gmail.com wrote:
  I'm rather consistently getting errors when I run ant clean test on
  Solr 3.x. Not saying that these area NOT on trunk, but I'm on 3.x at
  the moment.
 
  e.g.
 
  ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod2
  -Dtests.seed=-3b454f200cdffb4d:4d3124ee9a92369a:286699633a5841fc
  -Dargs=-Dfile.encoding=MacRoman
 
  ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod1
  -Dtests.seed=-3b454f200cdffb4d:-79099c4209c2611d:286699633a5841fc
  -Dargs=-Dfile.encoding=MacRoman
 
  ant test -Dtestcase=NonStringProperties -Dtestmethod=testMethod1
  -Dtests.seed=416ce6ff0a0c890b:5ca9698c9bf42fa1:286699633a5841fc
  -Dargs=-Dfile.encoding=MacRoman
 
 
  in TestSystemPropertiesInvariantRule
 
  Of course, they run fine when I run them individually. They run fine
  when I run them in IntelliJ. I'm running in the java 1.5, on OS X,
  took the code around 10:00 EDT 21-Mar.
 
 
  Is anyone else seeing this locally? I'm tempted to ignore it in terms
  of JIRAs I'm working on because it seems unlikely to be related to
  them.
 
  -
  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

FW: [NOTICE] Phasing out maven repos on people.apache.org

2012-03-21 Thread Steven A Rowe

FYI, as of next year, we will no longer be able to publish Maven artifacts as 
part of a release by putting them into the ibiblio directory on 
people.apache.org (see Joe Schaefer's message below).

When I switched the nightly Maven Jenkins jobs to deploy snapshots to the ASF 
Nexus snapshot repository (see 
https://issues.apache.org/jira/browse/LUCENE-3825), as part of signing 
Lucene/Solr up for using the repository, somebody from infrastructure deleted 
all contents under both the o.a.lucene and o.a.solr directories in the ibiblio 
directory on people.apache.org.  This was expected; according to 
http://www.apache.org/dev/publishing-maven-artifacts.html#signing-up: Move 
Existing Artifacts: In order to maintain the proper maven-metadata.xml files 
and to prevent rsync conflicts in Central, we must move all your artifacts to 
the new repository. We will move your artifacts from the old repository on 
people to the new repository and mark the folder in people as read-only to 
prevent accidental deployments.

I plan on using my own credentials to do some test release deployments to the 
ASF Nexus repo.  Note that there is a staging process, and I will be careful 
not to promote any of my tests to be real releases.

I'll update the Lucene/Solr release wiki pages once I've got it working.

Steve

From: Joe Schaefer [mailto:joe_schae...@yahoo.com]
Sent: Wednesday, March 21, 2012 3:01 PM
To: Apache Infrastructure
Subject: [NOTICE] Phasing out maven repos on people.apache.org

If your PMC does not use maven for distributing artifacts,
or you have already switched to using repository.apache.org,
you may disregard this notice.

Along with the rsyncs for websites, we will be shutting down
ALL maven repos currently hosted on people.apache.org in
Jan 2013.  For impacted projects please see

http://www.apache.org/dev/publishing-maven-artifacts.html#signing-up

Please direct all feedback on this change to 
infrastruct...@apache.orgmailto:infrastruct...@apache.org.
Thanks for your attention.

Re: Intermittent testing errors in TestSystemPropertiesInvariantRule

2012-03-21 Thread Erick Erickson

OK, I need some basic tutoring here. What constitutes a _real_ failure?
And is there a simple way to find them?

reproduce with doesn't necessarily work (obviously).

grep FAILED on the test results? That found what's below, but is
it sufficient to find them all?

Cause it appears that the real problem is, indeed, related to the changes
I've been making for SOLR-2921. At least this _really_ makes me
suspicious:
SEVERE: org.apache.solr.common.SolrException: Error loading class
'solr.ICUFoldingFilterFactory'

when I've been changing ICUFoldingFilterFactory (actually, this is probably
a byproduct of a schema definition)...

But I'd have gone ahead and checked it in based on not being able to fail
anything found with reproduce with, which is bad so I need to know
the magic...

Thanks,
Erick

On Wed, Mar 21, 2012 at 4:00 PM, Uwe Schindler u...@thetaphi.de wrote:
 Those in TestSystemPropertiesInvariantRule don't fail the build. Maybe
 another test failed before? The lengthly test output always shows up on
 Jenkins! (both 3.x and trunk)

 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de


 -Original Message-
 From: Erick Erickson [mailto:erickerick...@gmail.com]
 Sent: Wednesday, March 21, 2012 8:48 PM
 To: dev@lucene.apache.org
 Subject: Re: Intermittent testing errors in
 TestSystemPropertiesInvariantRule

 These are build-failing errors as far as I can tell. My touch-stone is
 that I get
 BUILD FAILED  at the end of the run...

 On Wed, Mar 21, 2012 at 3:03 PM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
  Hi Erick,
 
  These are not build-failing errors, are they? What you're seeing on
  the console  is most likely what's a side effect of running these test
  suites as part of another test; the way it works is I have some suites
  that test the testing framework itself so they launch another suite
  (nested class typically) _as part of the test_. Sometimes these nested
  suites cause exceptions or errors on purpose and this is what you see
  on the console.
 
  I suppressed System.out's on some suites but didn't have the time to
  clean it up for all of them yet. I'll take a look.
 
  Dawid
 
  On Wed, Mar 21, 2012 at 7:56 PM, Erick Erickson
 erickerick...@gmail.com wrote:
  I'm rather consistently getting errors when I run ant clean test on
  Solr 3.x. Not saying that these area NOT on trunk, but I'm on 3.x at
  the moment.
 
  e.g.
 
  ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod2
  -Dtests.seed=-3b454f200cdffb4d:4d3124ee9a92369a:286699633a5841fc
  -Dargs=-Dfile.encoding=MacRoman
 
  ant test -Dtestcase=InTestMethod -Dtestmethod=testMethod1
  -Dtests.seed=-3b454f200cdffb4d:-79099c4209c2611d:286699633a5841fc
  -Dargs=-Dfile.encoding=MacRoman
 
  ant test -Dtestcase=NonStringProperties -Dtestmethod=testMethod1
  -Dtests.seed=416ce6ff0a0c890b:5ca9698c9bf42fa1:286699633a5841fc
  -Dargs=-Dfile.encoding=MacRoman
 
 
  in TestSystemPropertiesInvariantRule
 
  Of course, they run fine when I run them individually. They run fine
  when I run them in IntelliJ. I'm running in the java 1.5, on OS X,
  took the code around 10:00 EDT 21-Mar.
 
 
  Is anyone else seeing this locally? I'm tempted to ignore it in terms
  of JIRAs I'm working on because it seems unlikely to be related to
  them.
 
  -
  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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #432: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/432/

3 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestScriptTransformer.testCheckScript

Error Message:
Cannot load Script Engine for language: JavaScript

Stack Trace:
org.apache.solr.handler.dataimport.DataImportHandlerException: Cannot load 
Script Engine for language: JavaScript
at 
org.apache.solr.handler.dataimport.ScriptTransformer.initEngine(ScriptTransformer.java:76)
at 
org.apache.solr.handler.dataimport.ScriptTransformer.transformRow(ScriptTransformer.java:53)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.applyTransformer(EntityProcessorWrapper.java:192)
at 
org.apache.solr.handler.dataimport.TestScriptTransformer.testCheckScript(TestScriptTransformer.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:37)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:39)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:37)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:39)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at

Re: Intermittent testing errors in TestSystemPropertiesInvariantRule

 grep FAILED on the test results? That found what's below, but is
 it sufficient to find them all?

The definite answer is each suite's summary line -- number of
failures/ errors being non-zero. I will silence those framework tests
to make life simpler.

 But I'd have gone ahead and checked it in based on not being able to fail
 anything found with reproduce with, which is bad so I need to know
 the magic...

As soon as we release 3.x I plan to merge in LUCENE-3808. It really
should make things simpler. Staszek's been working on a nice modern
html5 report; here's a peek at the recent build failure I got, for
example:

http://ophelia.cs.put.poznan.pl/~dweiss/lucene/tests-report-core/

The console output is also much, much cleaner as only those suites
that actually failed emit any output (verbose output is stored in
another file and error-only suites is yet another to speed up locating
the offender).

All the above requires infrastructural changes that go beyond my
ability to integrate with 3.x at the moment; I can hardly keep up with
merging changes from the trunk.

D.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #432: POMs out of sync

2012-03-21 Thread Dyer, James

I'm looking at it.

James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311


-Original Message-
From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] 
Sent: Wednesday, March 21, 2012 3:35 PM
To: dev@lucene.apache.org
Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #432: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/432/

3 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestScriptTransformer.testCheckScript

Error Message:
Cannot load Script Engine for language: JavaScript

Stack Trace:
org.apache.solr.handler.dataimport.DataImportHandlerException: Cannot load 
Script Engine for language: JavaScript
at 
org.apache.solr.handler.dataimport.ScriptTransformer.initEngine(ScriptTransformer.java:76)
at 
org.apache.solr.handler.dataimport.ScriptTransformer.transformRow(ScriptTransformer.java:53)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.applyTransformer(EntityProcessorWrapper.java:192)
at 
org.apache.solr.handler.dataimport.TestScriptTransformer.testCheckScript(TestScriptTransformer.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:37)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:39)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:37)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:39)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at

[jira] [Resolved] (SOLR-3263) Stop including more than one servlet-api jar version in the test classpath in the Maven build

2012-03-21 Thread Steven Rowe (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steven Rowe resolved SOLR-3263.
---

   Resolution: Fixed
Fix Version/s: 4.0

The errors are no longer occurring on the trunk Jenkins Maven job.

 Stop including more than one servlet-api jar version in the test classpath in 
 the Maven build
 -

 Key: SOLR-3263
 URL: https://issues.apache.org/jira/browse/SOLR-3263
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
 Fix For: 4.0

 Attachments: SOLR-3263.patch


 [Today's nightly Jenkins Maven trunk 
 build|https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/] 
 has several test failures with the error message:
 {noformat}
 class javax.servlet.FilterRegistration's signer information does not match 
 signer information of other classes in the same package
 {noformat}
 On SOLR-3260, [Ryan McKinley 
 mentioned|https://issues.apache.org/jira/browse/SOLR-3260?focusedCommentId=13234472page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13234472]
  that these errors can be caused by mixing servlet-api jar versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #432: POMs out of sync

2012-03-21 Thread Dyer, James

This is confusing me because the non-Maven build with this commit (#12834 on 
jenkins) passed.  So this JVM has the Rhino JavaScript engine.

I guess the Maven build (for Trunk) is using a different 1.6 JRE than the 
non-Maven build?  One without Rhino?  Is there any way to use the same JRE?

In any case, let me add the ignore back in for this one exception.  Its 
unlikely to mask a real problem and it will let people who have 
non-rhino-equipped 1.6 JVMs to have the tests pass.

I'll commit this shortly.

James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311


-Original Message-
From: Dyer, James [mailto:james.d...@ingrambook.com]
Sent: Wednesday, March 21, 2012 3:40 PM
To: dev@lucene.apache.org
Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #432: POMs out of sync

I'm looking at it.

James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311


-Original Message-
From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
Sent: Wednesday, March 21, 2012 3:35 PM
To: dev@lucene.apache.org
Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #432: POMs out of sync

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/432/

3 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestScriptTransformer.testCheckScript

Error Message:
Cannot load Script Engine for language: JavaScript

Stack Trace:
org.apache.solr.handler.dataimport.DataImportHandlerException: Cannot load 
Script Engine for language: JavaScript
at 
org.apache.solr.handler.dataimport.ScriptTransformer.initEngine(ScriptTransformer.java:76)
at 
org.apache.solr.handler.dataimport.ScriptTransformer.transformRow(ScriptTransformer.java:53)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.applyTransformer(EntityProcessorWrapper.java:192)
at 
org.apache.solr.handler.dataimport.TestScriptTransformer.testCheckScript(TestScriptTransformer.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:37)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:39)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:37)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:39)
at

Re: Intermittent testing errors in TestSystemPropertiesInvariantRule