date:20140222

Hi,

your commit is likely to fail when we start to restructure directory layouts. 
Tests should (whenever possible) always use the classpath to find the files in 
test-files (which is part of the classpath).
Attached is a patch with the recommended way. I suggest to fix this. 
ExternalPaths.SOURCE_HOME is unused in Solr test, the constant is just a relict 
and only used internally on setup of test infrastructure. Real tests should not 
use it.

There are more usages of this constant in test with absolute paths (including 
contrib/foobar/src/test-files to the contrib modules, I will open issue to 
fix those.

Uwe

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


 -Original Message-
 From: no...@apache.org [mailto:no...@apache.org]
 Sent: Saturday, February 22, 2014 7:19 AM
 To: comm...@lucene.apache.org
 Subject: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src:
 java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
 test-files/solrj/updateReq_4_5.bin
 test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java
 
 Author: noble
 Date: Sat Feb 22 06:19:16 2014
 New Revision: 1570793
 
 URL: http://svn.apache.org/r1570793
 Log:
 SOLR-5762 broke backward compatibility of Javabin format
 
 Added:
 lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin   (with
 props)
 Modified:
 
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java
 
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java
 
 Modified:
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java
 URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/apa
 che/solr/client/solrj/request/JavaBinUpdateRequestCodec.java?rev=157079
 3r1=1570792r2=1570793view=diff
 ==
 
 ---
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java (original)
 +++ lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/re
 +++ quest/JavaBinUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
 @@ -184,7 +184,13 @@ public class JavaBinUpdateRequestCodec {
  delByIdMap = (MapString,MapString,Object)
 namedList[0].get(delByIdMap);
  delByQ = (ListString) namedList[0].get(delByQ);
  doclist = (List) namedList[0].get(docs);
 -docMap =  (ListEntrySolrInputDocument,MapObject,Object)
 namedList[0].get(docsMap);
 +Object docsMapObj = namedList[0].get(docsMap);
 +
 +if (docsMapObj instanceof Map) {//SOLR-5762
 +  docMap =  new ArrayList(((Map)docsMapObj).entrySet());
 +} else {
 +  docMap = (ListEntrySolrInputDocument, MapObject, Object)
 docsMapObj;
 +}
 
 
  // we don't add any docs, because they were already processed
 
 Added: lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
 URL: http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test-
 files/solrj/updateReq_4_5.bin?rev=1570793view=auto
 ==
 
 Binary file - no diff available.
 
 Modified:
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java
 URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test/org/apa
 che/solr/client/solrj/request/TestUpdateRequestCodec.java?rev=1570793r
 1=1570792r2=1570793view=diff
 ==
 
 ---
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java (original)
 +++ lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/re
 +++ quest/TestUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
 @@ -18,6 +18,9 @@ package org.apache.solr.client.solrj.req
 
  import java.io.ByteArrayInputStream;
  import java.io.ByteArrayOutputStream;
 +import java.io.File;
 +import java.io.FileInputStream;
 +import java.io.FileOutputStream;
  import java.io.IOException;
  import java.util.ArrayList;
  import java.util.Collection;
 @@ -31,6 +34,7 @@ import junit.framework.Assert;  import
 org.apache.lucene.util.LuceneTestCase;
  import org.apache.solr.common.SolrInputDocument;
  import org.apache.solr.common.SolrInputField;
 +import org.apache.solr.util.ExternalPaths;
  import org.junit.Test;
 
  /**
 @@ -160,6 +164,75 @@ public class TestUpdateRequestCodec exte
 
 
 
 +  public void testBackCompat4_5() throws IOException {
 +
 +UpdateRequest updateRequest = new UpdateRequest();
 +updateRequest.deleteById(*:*);
 +updateRequest.deleteById(id:5);
 +updateRequest.deleteByQuery(2*);
 +updateRequest.deleteByQuery(1*);
 +updateRequest.setParam(a, b);
 +SolrInputDocument doc = new SolrInputDocument();
 +doc.addField(id, 1);
 +

RE: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src: java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java test-files/solrj/updateReq_4_5.bin test/org/apache/solr/client/

2014-02-22 Thread Noble Paul നോബിള്‍ नोब्ळ्

Alternatively you can use SolrTestCaseJ4.getFile() if you really need a file. 
In that case, an input stream was enough, so this is the simplier variant.

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


 -Original Message-
 From: Uwe Schindler [mailto:u...@thetaphi.de]
 Sent: Saturday, February 22, 2014 10:02 AM
 To: dev@lucene.apache.org
 Subject: RE: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src:
 java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
 test-files/solrj/updateReq_4_5.bin
 test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java
 
 Hi,
 
 your commit is likely to fail when we start to restructure directory layouts.
 Tests should (whenever possible) always use the classpath to find the files in
 test-files (which is part of the classpath).
 Attached is a patch with the recommended way. I suggest to fix this.
 ExternalPaths.SOURCE_HOME is unused in Solr test, the constant is just a
 relict and only used internally on setup of test infrastructure. Real tests
 should not use it.
 
 There are more usages of this constant in test with absolute paths
 (including contrib/foobar/src/test-files to the contrib modules, I will open
 issue to fix those.
 
 Uwe
 
 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
 
 
  -Original Message-
  From: no...@apache.org [mailto:no...@apache.org]
  Sent: Saturday, February 22, 2014 7:19 AM
  To: comm...@lucene.apache.org
  Subject: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src:
  java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.ja
  va
  test-files/solrj/updateReq_4_5.bin
  test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java
 
  Author: noble
  Date: Sat Feb 22 06:19:16 2014
  New Revision: 1570793
 
  URL: http://svn.apache.org/r1570793
  Log:
  SOLR-5762 broke backward compatibility of Javabin format
 
  Added:
  lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
 (with
  props)
  Modified:
 
  lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/requ
  est/Ja
  vaBinUpdateRequestCodec.java
 
  lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/requ
  est/T
  estUpdateRequestCodec.java
 
  Modified:
  lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/requ
  est/Ja
  vaBinUpdateRequestCodec.java
  URL:
  http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/
  apa
 
 che/solr/client/solrj/request/JavaBinUpdateRequestCodec.java?rev=15707
  9
  3r1=1570792r2=1570793view=diff
 
 ==
  
  ---
  lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/requ
  est/Ja vaBinUpdateRequestCodec.java (original)
  +++ lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/
  +++ re quest/JavaBinUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
  @@ -184,7 +184,13 @@ public class JavaBinUpdateRequestCodec {
   delByIdMap = (MapString,MapString,Object)
  namedList[0].get(delByIdMap);
   delByQ = (ListString) namedList[0].get(delByQ);
   doclist = (List) namedList[0].get(docs);
  -docMap =  (ListEntrySolrInputDocument,MapObject,Object)
  namedList[0].get(docsMap);
  +Object docsMapObj = namedList[0].get(docsMap);
  +
  +if (docsMapObj instanceof Map) {//SOLR-5762
  +  docMap =  new ArrayList(((Map)docsMapObj).entrySet());
  +} else {
  +  docMap = (ListEntrySolrInputDocument, MapObject, Object)
  docsMapObj;
  +}
 
 
   // we don't add any docs, because they were already processed
 
  Added:
  lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
  URL:
  http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test-
  files/solrj/updateReq_4_5.bin?rev=1570793view=auto
 
 ==
  
  Binary file - no diff available.
 
  Modified:
  lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/requ
  est/T
  estUpdateRequestCodec.java
  URL:
  http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test/org/
  apa
 
 che/solr/client/solrj/request/TestUpdateRequestCodec.java?rev=1570793
  r
  1=1570792r2=1570793view=diff
 
 ==
  
  ---
  lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/requ
  est/T
  estUpdateRequestCodec.java (original)
  +++ lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/
  +++ re quest/TestUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
  @@ -18,6 +18,9 @@ package org.apache.solr.client.solrj.req
 
   import java.io.ByteArrayInputStream;
   import java.io.ByteArrayOutputStream;
  +import java.io.File;
  +import java.io.FileInputStream;
  +import java.io.FileOutputStream;
   import java.io.IOException;
   import

RE: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src: java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java test-files/solrj/updateReq_4_5.bin test/org/apache/solr/client/

Sure.
let's change the location one we identify the right place.
I hope we don't need to block 4.7 for this
On 22 Feb 2014 14:32, Uwe Schindler u...@thetaphi.de wrote:

 Hi,

 your commit is likely to fail when we start to restructure directory
 layouts. Tests should (whenever possible) always use the classpath to find
 the files in test-files (which is part of the classpath).
 Attached is a patch with the recommended way. I suggest to fix this.
 ExternalPaths.SOURCE_HOME is unused in Solr test, the constant is just a
 relict and only used internally on setup of test infrastructure. Real tests
 should not use it.

 There are more usages of this constant in test with absolute paths
 (including contrib/foobar/src/test-files to the contrib modules, I will
 open issue to fix those.

 Uwe

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


  -Original Message-
  From: no...@apache.org [mailto:no...@apache.org]
  Sent: Saturday, February 22, 2014 7:19 AM
  To: comm...@lucene.apache.org
  Subject: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src:
  java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
  test-files/solrj/updateReq_4_5.bin
  test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java
 
  Author: noble
  Date: Sat Feb 22 06:19:16 2014
  New Revision: 1570793
 
  URL: http://svn.apache.org/r1570793
  Log:
  SOLR-5762 broke backward compatibility of Javabin format
 
  Added:
  lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
 (with
  props)
  Modified:
 
 
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
  vaBinUpdateRequestCodec.java
 
 
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
  estUpdateRequestCodec.java
 
  Modified:
 
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
  vaBinUpdateRequestCodec.java
  URL:
 
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/apa
  che/solr/client/solrj/request/JavaBinUpdateRequestCodec.java?rev=157079
  3r1=1570792r2=1570793view=diff
  ==
  
  ---
 
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
  vaBinUpdateRequestCodec.java (original)
  +++ lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/re
  +++ quest/JavaBinUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
  @@ -184,7 +184,13 @@ public class JavaBinUpdateRequestCodec {
   delByIdMap = (MapString,MapString,Object)
  namedList[0].get(delByIdMap);
   delByQ = (ListString) namedList[0].get(delByQ);
   doclist = (List) namedList[0].get(docs);
  -docMap =  (ListEntrySolrInputDocument,MapObject,Object)
  namedList[0].get(docsMap);
  +Object docsMapObj = namedList[0].get(docsMap);
  +
  +if (docsMapObj instanceof Map) {//SOLR-5762
  +  docMap =  new ArrayList(((Map)docsMapObj).entrySet());
  +} else {
  +  docMap = (ListEntrySolrInputDocument, MapObject, Object)
  docsMapObj;
  +}
 
 
   // we don't add any docs, because they were already processed
 
  Added: lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
  URL: http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test-
  files/solrj/updateReq_4_5.bin?rev=1570793view=auto
  ==
  
  Binary file - no diff available.
 
  Modified:
 
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
  estUpdateRequestCodec.java
  URL:
 
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test/org/apa
  che/solr/client/solrj/request/TestUpdateRequestCodec.java?rev=1570793r
  1=1570792r2=1570793view=diff
  ==
  
  ---
 
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
  estUpdateRequestCodec.java (original)
  +++ lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/re
  +++ quest/TestUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
  @@ -18,6 +18,9 @@ package org.apache.solr.client.solrj.req
 
   import java.io.ByteArrayInputStream;
   import java.io.ByteArrayOutputStream;
  +import java.io.File;
  +import java.io.FileInputStream;
  +import java.io.FileOutputStream;
   import java.io.IOException;
   import java.util.ArrayList;
   import java.util.Collection;
  @@ -31,6 +34,7 @@ import junit.framework.Assert;  import
  org.apache.lucene.util.LuceneTestCase;
   import org.apache.solr.common.SolrInputDocument;
   import org.apache.solr.common.SolrInputField;
  +import org.apache.solr.util.ExternalPaths;
   import org.junit.Test;
 
   /**
  @@ -160,6 +164,75 @@ public class TestUpdateRequestCodec exte
 
 
 
  +  public void testBackCompat4_5() throws IOException {
  +
  +UpdateRequest updateRequest = new UpdateRequest();
  +

RE: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src: java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java test-files/solrj/updateReq_4_5.bin test/org/apache/solr/client/

Hi,

 

No thats fine, does not block 4.7. I am currently fixing the remaining stuff in 
code recently donated that also violated this (especially the analytics module 
+ mapreduce)

 

I will open issue and fix your’s, too.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 http://www.thetaphi.de/ http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Noble Paul നോബിള്‍ नोब्ळ् [mailto:noble.p...@gmail.com] 
Sent: Saturday, February 22, 2014 10:53 AM
To: Lucene Dev
Subject: RE: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src: 
java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java 
test-files/solrj/updateReq_4_5.bin 
test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java

 

Sure.
let's change the location one we identify the right place.
I hope we don't need to block 4.7 for this

On 22 Feb 2014 14:32, Uwe Schindler u...@thetaphi.de wrote:

Hi,

your commit is likely to fail when we start to restructure directory layouts. 
Tests should (whenever possible) always use the classpath to find the files in 
test-files (which is part of the classpath).
Attached is a patch with the recommended way. I suggest to fix this. 
ExternalPaths.SOURCE_HOME is unused in Solr test, the constant is just a relict 
and only used internally on setup of test infrastructure. Real tests should not 
use it.

There are more usages of this constant in test with absolute paths (including 
contrib/foobar/src/test-files to the contrib modules, I will open issue to 
fix those.

Uwe

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


 -Original Message-
 From: no...@apache.org [mailto:no...@apache.org]
 Sent: Saturday, February 22, 2014 7:19 AM
 To: comm...@lucene.apache.org
 Subject: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src:
 java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
 test-files/solrj/updateReq_4_5.bin
 test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java

 Author: noble
 Date: Sat Feb 22 06:19:16 2014
 New Revision: 1570793

 URL: http://svn.apache.org/r1570793
 Log:
 SOLR-5762 broke backward compatibility of Javabin format

 Added:
 lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin   (with
 props)
 Modified:

 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java

 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java

 Modified:
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java
 URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/apa
 che/solr/client/solrj/request/JavaBinUpdateRequestCodec.java?rev=157079
 3r1=1570792r2=1570793view=diff
 ==
 
 ---
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java (original)
 +++ lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/re
 +++ quest/JavaBinUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
 @@ -184,7 +184,13 @@ public class JavaBinUpdateRequestCodec {
  delByIdMap = (MapString,MapString,Object)
 namedList[0].get(delByIdMap);
  delByQ = (ListString) namedList[0].get(delByQ);
  doclist = (List) namedList[0].get(docs);
 -docMap =  (ListEntrySolrInputDocument,MapObject,Object)
 namedList[0].get(docsMap);
 +Object docsMapObj = namedList[0].get(docsMap);
 +
 +if (docsMapObj instanceof Map) {//SOLR-5762
 +  docMap =  new ArrayList(((Map)docsMapObj).entrySet());
 +} else {
 +  docMap = (ListEntrySolrInputDocument, MapObject, Object)
 docsMapObj;
 +}


  // we don't add any docs, because they were already processed

 Added: lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
 URL: http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test-
 files/solrj/updateReq_4_5.bin?rev=1570793view=auto
 ==
 
 Binary file - no diff available.

 Modified:
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java
 URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test/org/apa
 che/solr/client/solrj/request/TestUpdateRequestCodec.java?rev=1570793r
 1=1570792r2=1570793view=diff
 ==
 
 ---
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java (original)
 +++ lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/re
 +++ quest/TestUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
 @@ -18,6 +18,9 @@ package org.apache.solr.client.solrj.req

  import java.io.ByteArrayInputStream;
  import java.io.ByteArrayOutputStream;
 +import java.io.File;

RE: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src: java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java test-files/solrj/updateReq_4_5.bin test/org/apache/solr/client/

You might not have seen it, I attached a patch to my original mail fixing the 
issue. I may commit this together with my remaining fixes at other places using 
“absolute” paths.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 http://www.thetaphi.de/ http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Noble Paul നോബിള്‍ नोब्ळ् [mailto:noble.p...@gmail.com] 
Sent: Saturday, February 22, 2014 10:53 AM
To: Lucene Dev
Subject: RE: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src: 
java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java 
test-files/solrj/updateReq_4_5.bin 
test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java

 

Sure.
let's change the location one we identify the right place.
I hope we don't need to block 4.7 for this

On 22 Feb 2014 14:32, Uwe Schindler u...@thetaphi.de wrote:

Hi,

your commit is likely to fail when we start to restructure directory layouts. 
Tests should (whenever possible) always use the classpath to find the files in 
test-files (which is part of the classpath).
Attached is a patch with the recommended way. I suggest to fix this. 
ExternalPaths.SOURCE_HOME is unused in Solr test, the constant is just a relict 
and only used internally on setup of test infrastructure. Real tests should not 
use it.

There are more usages of this constant in test with absolute paths (including 
contrib/foobar/src/test-files to the contrib modules, I will open issue to 
fix those.

Uwe

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


 -Original Message-
 From: no...@apache.org [mailto:no...@apache.org]
 Sent: Saturday, February 22, 2014 7:19 AM
 To: comm...@lucene.apache.org
 Subject: svn commit: r1570793 - in /lucene/dev/trunk/solr/solrj/src:
 java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
 test-files/solrj/updateReq_4_5.bin
 test/org/apache/solr/client/solrj/request/TestUpdateRequestCodec.java

 Author: noble
 Date: Sat Feb 22 06:19:16 2014
 New Revision: 1570793

 URL: http://svn.apache.org/r1570793
 Log:
 SOLR-5762 broke backward compatibility of Javabin format

 Added:
 lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin   (with
 props)
 Modified:

 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java

 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java

 Modified:
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java
 URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/apa
 che/solr/client/solrj/request/JavaBinUpdateRequestCodec.java?rev=157079
 3r1=1570792r2=1570793view=diff
 ==
 
 ---
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/request/Ja
 vaBinUpdateRequestCodec.java (original)
 +++ lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/re
 +++ quest/JavaBinUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
 @@ -184,7 +184,13 @@ public class JavaBinUpdateRequestCodec {
  delByIdMap = (MapString,MapString,Object)
 namedList[0].get(delByIdMap);
  delByQ = (ListString) namedList[0].get(delByQ);
  doclist = (List) namedList[0].get(docs);
 -docMap =  (ListEntrySolrInputDocument,MapObject,Object)
 namedList[0].get(docsMap);
 +Object docsMapObj = namedList[0].get(docsMap);
 +
 +if (docsMapObj instanceof Map) {//SOLR-5762
 +  docMap =  new ArrayList(((Map)docsMapObj).entrySet());
 +} else {
 +  docMap = (ListEntrySolrInputDocument, MapObject, Object)
 docsMapObj;
 +}


  // we don't add any docs, because they were already processed

 Added: lucene/dev/trunk/solr/solrj/src/test-files/solrj/updateReq_4_5.bin
 URL: http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test-
 files/solrj/updateReq_4_5.bin?rev=1570793view=auto
 ==
 
 Binary file - no diff available.

 Modified:
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java
 URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test/org/apa
 che/solr/client/solrj/request/TestUpdateRequestCodec.java?rev=1570793r
 1=1570792r2=1570793view=diff
 ==
 
 ---
 lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/request/T
 estUpdateRequestCodec.java (original)
 +++ lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/client/solrj/re
 +++ quest/TestUpdateRequestCodec.java Sat Feb 22 06:19:16 2014
 @@ -18,6 +18,9 @@ package org.apache.solr.client.solrj.req

  import java.io.ByteArrayInputStream;
  import java.io.ByteArrayOutputStream;
 +import java.io.File;
 +import java.io.FileInputStream;
 +import

[VOTE] Lucene / Solr 4.7.0 RC4

2014-02-22 Thread Simon Willnauer

Please vote for the forth Release Candidate for Lucene/Solr 4.7.0

you can download it here:
http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC4-rev1570806/
or run the smoke tester directly with this commandline (don't forget
to set JAVA6_HOME etc.):

$ python3.2 -u dev-tools/scripts/smokeTestRelease.py
http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC4-rev1570806/
1570806 4.7.0 /tmp/smoke_test_4_7

Smoketester said: SUCCESS!

here is my +1

This RC includes the following fixes compared to RC3


r1570798 | noble | 2014-02-22 07:50:02 +0100 (Sat, 22 Feb 2014) | 1 line
SOLR-3854 urlScheme property should be whitelisted

r1570795 | noble | 2014-02-22 07:42:22 +0100 (Sat, 22 Feb 2014) | 1 line
SOLR-5762 broke backward compatibility of Javabin format

r1570772 | sarowe | 2014-02-22 01:49:11 +0100 (Sat, 22 Feb 2014) | 1 line
Fix CHANGES.txt to reflect the twisted evolution and current state of
the Admin UI Files conf directory File Browser.  (merged branch_4x
r1570771)

r1570741 | sarowe | 2014-02-21 23:51:47 +0100 (Fri, 21 Feb 2014) | 1 line
LUCENE-5465: Solr Contrib map-reduce breaks Manifest of all other JAR
files by adding a broken Main-Class attribute (merged trunk r1570738)

r1570628 | sarowe | 2014-02-21 17:38:59 +0100 (Fri, 21 Feb 2014) | 1 line
SOLR-5729: intellij config (merge trunk r1570626)

r1570576 | mvg | 2014-02-21 15:06:41 +0100 (Fri, 21 Feb 2014) | 2 lines
Fixed typo in CHANGES.txt for issue LUCENE-5399 and moved that issue
under optimizations.

r1570562 | mikemccand | 2014-02-21 13:49:47 +0100 (Fri, 21 Feb 2014) | 1 line
LUCENE-5461: fix thread hazard in ControlledRealTimeReopenThread
causing a possible too-long wait time when a thread was waiting for a
specific generation

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

[jira] [Commented] (LUCENE-5460) Allow driving a query by sparse filters

2014-02-22 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-5460:
-

That would have considerable api impact. Today its assumed that nextDoc/advance
are correct and lots of code assumes this.

I'm unwilling to let our APIs go to trash for the stuff on this issue: I know
it will make a lot of people unhappy, but someone has to prevent them from
going crazy. Performance is just not the most important thing.

Allow driving a query by sparse filters
---

Key: LUCENE-5460
URL: https://issues.apache.org/jira/browse/LUCENE-5460
Project: Lucene - Core
Issue Type: Improvement
Components: core/search
Reporter: Shai Erera

Today if a filter is very sparse we execute the query in sort of a leap-frog
manner between the query and filter. If the query is very expensive to
compute, and/or matching few docs only too, calling scorer.advance(doc) just
to discover the doc it landed on isn't accepted by the filter, is a waste of
time. Since Filter is always the final ruler, I wonder if we had something
like {{boolean DISI.advanceExact(doc)}} we could use it instead, in some
cases.
There are many combinations in which I think we'd want to use/not-use this
API, and they depend on: Filter's complexity, Filter.cost(), Scorer.cost(),
query complexity (span-near, many clauses) etc.
I open an issue so we can discuss. DISI.advanceExact(doc) is just a
preliminary proposal, to get an API we could experiment with. The default
implementation should be fairly easy and straightforward, and we could
override where we can offer a more optimized imp.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Re: [VOTE] Lucene / Solr 4.7.0 RC4

2014-02-22 Thread Steve Davids

Hate to bring this up, though it must have gotten lost in the shuffle. When 
migrating from http - https in SOLR-3854 shards aren’t obtaining their old 
core node name and resuming their prior assignments. This is because the 
base_url is being compared instead (which changed) instead of something more 
constant like the node_name. A patch was attached yesterday: 
https://issues.apache.org/jira/browse/SOLR-3854?focusedCommentId=13908014page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13908014.
 It is a quick patch that hasn’t really been tested yet, will do so later this 
evening.

The current work-around would be that if clients want to migrate to https, they 
will need to shutdown their servers, migrate the cluster state’s base_url from 
http to https and bring the server back up.

-Steve

On Feb 22, 2014, at 5:46 AM, Simon Willnauer simon.willna...@gmail.com wrote:

 Please vote for the forth Release Candidate for Lucene/Solr 4.7.0
 
 you can download it here:
 http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC4-rev1570806/
 or run the smoke tester directly with this commandline (don't forget
 to set JAVA6_HOME etc.):
 
 $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
 http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC4-rev1570806/
 1570806 4.7.0 /tmp/smoke_test_4_7
 
 Smoketester said: SUCCESS!
 
 here is my +1
 
 This RC includes the following fixes compared to RC3
 
 
 r1570798 | noble | 2014-02-22 07:50:02 +0100 (Sat, 22 Feb 2014) | 1 line
 SOLR-3854 urlScheme property should be whitelisted
 
 r1570795 | noble | 2014-02-22 07:42:22 +0100 (Sat, 22 Feb 2014) | 1 line
 SOLR-5762 broke backward compatibility of Javabin format
 
 r1570772 | sarowe | 2014-02-22 01:49:11 +0100 (Sat, 22 Feb 2014) | 1 line
 Fix CHANGES.txt to reflect the twisted evolution and current state of
 the Admin UI Files conf directory File Browser.  (merged branch_4x
 r1570771)
 
 r1570741 | sarowe | 2014-02-21 23:51:47 +0100 (Fri, 21 Feb 2014) | 1 line
 LUCENE-5465: Solr Contrib map-reduce breaks Manifest of all other JAR
 files by adding a broken Main-Class attribute (merged trunk r1570738)
 
 r1570628 | sarowe | 2014-02-21 17:38:59 +0100 (Fri, 21 Feb 2014) | 1 line
 SOLR-5729: intellij config (merge trunk r1570626)
 
 r1570576 | mvg | 2014-02-21 15:06:41 +0100 (Fri, 21 Feb 2014) | 2 lines
 Fixed typo in CHANGES.txt for issue LUCENE-5399 and moved that issue
 under optimizations.
 
 r1570562 | mikemccand | 2014-02-21 13:49:47 +0100 (Fri, 21 Feb 2014) | 1 line
 LUCENE-5461: fix thread hazard in ControlledRealTimeReopenThread
 causing a possible too-long wait time when a thread was waiting for a
 specific generation
 
 -
 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] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1356 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1356/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 423 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/core/test/temp/junit4-J0-20140222_140021_890.sysout
   [junit4]  JVM J0: stdout (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x000110d83aea, pid=143, tid=26671
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 
1.7.0_51-b13)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode 
bsd-amd64 )
   [junit4] # Problematic frame:
   [junit4] # J  
org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get(I)Lorg/apache/lucene/index/Fields;
   [junit4] #
   [junit4] # Failed to write core dump. Core dumps have been disabled. To 
enable core dumping, try ulimit -c unlimited before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/core/test/J0/hs_err_pid143.log
   [junit4] Compiled method (c2)   50781 1425 
org.apache.lucene.codecs.compressing.CompressingTermVectorsReader::get (2770 
bytes)
   [junit4]  total in heap  [0x000110d816d0,0x000110d93770] = 73888
   [junit4]  relocation [0x000110d817f0,0x000110d81eb8] = 1736
   [junit4]  main code  [0x000110d81ec0,0x000110d89ac0] = 31744
   [junit4]  stub code  [0x000110d89ac0,0x000110d89e68] = 936
   [junit4]  oops   [0x000110d89e68,0x000110d89f30] = 200
   [junit4]  scopes data[0x000110d89f30,0x000110d91b28] = 31736
   [junit4]  scopes pcs [0x000110d91b28,0x000110d92bf8] = 4304
   [junit4]  dependencies   [0x000110d92bf8,0x000110d92c00] = 8
   [junit4]  handler table  [0x000110d92c00,0x000110d934e8] = 2280
   [junit4]  nul chk table  [0x000110d934e8,0x000110d93770] = 648
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.sun.com/bugreport/crash.jsp
   [junit4] #
   [junit4]  JVM J0: EOF 

[...truncated 1 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre/bin/java 
-XX:-UseCompressedOops -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/heapdumps 
-Dtests.prefix=tests -Dtests.seed=12BCFD5DF06F0349 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 
-Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/core/test/temp
 
-Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/tests.policy
 -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.disableHdfs=true -classpath

[jira] [Commented] (LUCENE-5460) Allow driving a query by sparse filters

2014-02-22 Thread David Smiley (JIRA)

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

David Smiley commented on LUCENE-5460:
--

+1 Rob. I very much agree it would be quite confusing to complicate the
definition of these existing methods in this way.

Allow driving a query by sparse filters
---

Key: LUCENE-5460
URL: https://issues.apache.org/jira/browse/LUCENE-5460
Project: Lucene - Core
Issue Type: Improvement
Components: core/search
Reporter: Shai Erera

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[JENKINS] Lucene-Solr-SmokeRelease-4.x - Build # 153 - Still Failing

2014-02-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-4.x/153/

No tests ran.

Build Log:
[...truncated 51557 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease
 [copy] Copying 431 files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease/lucene
 [copy] Copying 239 files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease/solr
 [exec] JAVA6_HOME is /home/hudson/tools/java/latest1.6
 [exec] JAVA7_HOME is /home/hudson/tools/java/latest1.7
 [exec] NOTE: output encoding is US-ASCII
 [exec] 
 [exec] Load release URL 
file:/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease/...
 [exec] 
 [exec] Test Lucene...
 [exec]   test basics...
 [exec]   get KEYS
 [exec] 0.1 MB in 0.01 sec (14.3 MB/sec)
 [exec]   check changes HTML...
 [exec] Traceback (most recent call last):
 [exec]   File 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
 line 1377, in module
 [exec] main()
 [exec]   File 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
 line 1321, in main
 [exec] smokeTest(baseURL, svnRevision, version, tmpDir, isSigned, 
testArgs)
 [exec]   File 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
 line 1356, in smokeTest
 [exec] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
 [exec]   File 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
 line 418, in checkSigs
 [exec] testChanges(project, version, changesURL)
 [exec]   File 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
 line 466, in testChanges
 [exec] checkChangesContent(s, version, changesURL, project, True)
 [exec]   File 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
 line 483, in checkChangesContent
 [exec] raise RuntimeError('did not see Release %s in %s' % (version, 
name))
 [exec] RuntimeError: did not see Release 4.8.0 in 
file:///usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease/lucene/changes/Changes.html

BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/build.xml:378:
 exec returned: 1

Total time: 29 minutes 59 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure



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

Re: [VOTE] Lucene / Solr 4.7.0 RC3

2014-02-22 Thread Mark Miller

I’ve been sick and am sick, so take it for what it’s worth with my head 
swirling, but I wrote down a few of my thoughts on releases.

It’s all encompassed in a big “in my opinion”. It’s not necessarily to refute 
anyone or argue with any existing points. It’s just the thoughts I had when 
thinking about the topic.

Releases

I think we have to balance the utility of getting code into users hands faster 
with the utility of solid and stable releases. Balance the needs of new users 
and existing users. 

We shouldn't discourage review and reporting back of problems with the release. 
That is the entire point of the review and vote. We learn which bugs are worth 
a respin with discussion and consensus. 

We should be lenient on the first couple RCs and more strict over time. Let's 
aim for quality. 

We should discuss issues and not try and move at light speed. We are a large 
group of diverse developers - it's okay for things to move at a pace of days. 
It's actually the Apache Way IMO. 

Potential RMs that don't want to respin may not be the best candidate RM's. Or 
they should be willing to hand off the reigns for another to respin. That 
doesn’t mean you have to respin or can’t argue against it. But it seems like 
you should be pretty open to the idea if their strong support for it.

Releasing often should be a goal. Making releases easy to do should be a goal. 
Releasing fast is not necessarily a good goal. We should strive for quality. 
People choose a release and are often stuck on it for a very long time. A 
respin amounts to running a few cmds. It is mostly waiting. And it’s easily 
passed off if your busy. Robert happily picked up the last bits of the 4.6.1 
release for me when I had to go out of town for a few days. I would do the same 
for anyone here.

I can't think of a reason for delaying a release a few days or even a week if 
we can make it higher quality in a way discussion and consensus has deemed 
important. Company deadlines seem like the only reason we wouldn't do this and 
they shouldn't play a role in our releases. I don’t think we should try and 
setup a system that tries to avoid discussion and consensus - I think you just 
need a fail safe to help ensure it doesn’t go on to long. I think discussion 
and consensus with the community of developers we have put together is a good 
failsafe. In general, we all seem pretty good at coming to consensus in most 
cases. I can’t be the only one to notice how we seem to end up working almost 
everything out pretty nicely in the end.

Common sense has always worked for us in the past - the community would not 
delay a release for weeks just to fix a few superficial bugs. 

Looking critically at our last half dozen releases, I think things went pretty 
well and at a great pace. 

- Mark

http://about.me/markrmiller




On Feb 21, 2014, at 10:27 AM, Robert Muir rcm...@gmail.com wrote:

 
 
 
 On Fri, Feb 21, 2014 at 10:23 AM, Uwe Schindler u...@thetaphi.de wrote:
 
 A similar thing was already discussed on the board. I think we have to stick 
 with the 72 hours (for now?). We can do releases once per week; we can also 
 do them automatically - the problem here is the GPG signature: It has to be 
 done by a real person (the RM). A machine as RM is therefore not possible.
  
 I agree a machine cannot be the complete RM, but it could take over more. For 
 example, a machine could prepare-release-no-sign and verify it (actually this 
 is what 'ant nightly-smoke' does!), and if it succeeds, someone could take 
 those artifacts, sign them, and call a vote.


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

[jira] [Commented] (SOLR-5730) make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector configurable in Solr

2014-02-22 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-5730:


[~cpoerschke], are you in a position to build a test that makes sure everything 
does what it's expected to do, ideally when the new feature is disabled as well 
as enabled?  I'm evaluating whether or not I can take this issue on.  My 
understanding of how to use Lucene is pretty low, and I'm a little wobbly on 
crafting new tests.

 make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector 
 configurable in Solr
 --

 Key: SOLR-5730
 URL: https://issues.apache.org/jira/browse/SOLR-5730
 Project: Solr
  Issue Type: New Feature
Reporter: Christine Poerschke
Priority: Minor

 Example configuration:
 solrconfig.xml
 {noformat}
 mergeSorter class=org.apache.solr.update.DefaultMergeSorterFactory/
 {noformat}
 schema.xml
 {noformat}
 mergeSorterKey class=org.apache.solr.schema.SingleFieldSorterFactory
   str name=fieldNametimestamp/str
   bool name=ascendingfalse/bool
 /mergeSorterKey
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicate

Uwe Schindler created SOLR-5764:
---

 Summary: Fix recently added tests to *not* use absolute paths to 
load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix 
morphlines/map-reduce to not duplicate test resources and fix dependencies 
among them
 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0


Tests that were recently added have the problems that some of them were using 
{{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. This 
makes it impossible to move modules around or run them standalone.

This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
openResourceAsStream from classpath, because all {{test-files}} are located in 
classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so nothing 
can use it anymore - so no new tests should appear using them again.

While doing this, I recognized that the recently added morphlines and mapreduce 
contribs are duplicating modified solr example folders into their test-files 
folder, while morphlines-core was referring from inside the tests to 
map-reduce/test-files (ignoring the whole megabytes of test-files of 
morphlines!!! Easy to see, because the config files in it were just broken and 
referring to non-existent classes). This is the reverse of the natural 
dependency, where map-reduce uses morphlines as dep.

The fix here is to completely delete/empty the test-files folders of map-reduce 
and morphlines-cell and let those reuse the one from morphlines-core. 
Morphlines-core is now the only source folder for test-files, shared by all 
three contribs. Its contents are now the previous map-reduce/test-files folder.

I will provide a patch with the code changes, but the cleanup of morphlines 
test-files cannot be described here, it is too crazy. I will just heavy commit 
the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

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

Mark Miller commented on SOLR-5764:
---

Thanks Uwe! Yeah, there was a bunch of duplication because the initial code was
not developed in the project. I focused pretty much just on getting something
committed that could pass all our checks and tests, so there is probably a fair
amount of cleanup yet to do. That's part of the driving force behind marking it
experimental. It would also be good to take into account other developers
opinions on the API's and such.

Fix recently added tests to *not* use absolute paths to load resources, use
SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce
to not duplicate test resources and fix dependencies among them
-

Key: SOLR-5764
URL: https://issues.apache.org/jira/browse/SOLR-5764
Project: Solr
Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 4.8, 5.0

Tests that were recently added have the problems that some of them were using
{{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules.
This makes it impossible to move modules around or run them standalone.
This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple
openResourceAsStream from classpath, because all {{test-files}} are located
in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so
nothing can use it anymore - so no new tests should appear using them again.
While doing this, I recognized that the recently added morphlines and
mapreduce contribs are duplicating modified solr example folders into their
test-files folder, while morphlines-core was referring from inside the tests
to map-reduce/test-files (ignoring the whole megabytes of test-files of
morphlines!!! Easy to see, because the config files in it were just broken
and referring to non-existent classes). This is the reverse of the natural
dependency, where map-reduce uses morphlines as dep.
The fix here is to completely delete/empty the test-files folders of
map-reduce and morphlines-cell and let those reuse the one from
morphlines-core. Morphlines-core is now the only source folder for
test-files, shared by all three contribs. Its contents are now the previous
map-reduce/test-files folder.
I will provide a patch with the code changes, but the cleanup of morphlines
test-files cannot be described here, it is too crazy. I will just heavy
commit the changes, sorry!

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Re: 4.7 CHANGES.txt and editing schema.xml and solrconfig.xml [was: Re: [VOTE] Lucene / Solr 4.7.0 RC1]

2014-02-22 Thread Stefan Matheis

Looks good to me, thanks Steve :)  

-Stefan  


On Saturday, February 22, 2014 at 2:16 AM, Steve Rowe wrote:

 On Feb 21, 2014, at 3:56 PM, Steve Rowe sar...@gmail.com 
 (mailto:sar...@gmail.com) wrote:
  
  Hi Cassandra,
   
  On Feb 19, 2014, at 12:00 PM, Cassandra Targett casstarg...@gmail.com 
  (mailto:casstarg...@gmail.com) wrote:
   
   I'm starting to look at what needs to be updated in the ref guide, and I 
   noticed a number of references in changes.txt to the issues for being 
   able to update solrconfig.xml and schema.xml (SOLR-5287, 5446, 5456, 
   maybe others) and then another reference to removing that functionality 
   from 4.x (SOLR-5522). Shouldn't changes.txt for 4.7 be updated to remove 
   the references to something that was basically reverted? Just from 
   looking at that list, I'm confused about if that stuff works or not.
   
   
  I chatted with Erick Erickson and Stefan Matheis, and they’ve agreed to let 
  me try to sort out the 4.7 CHANGES.txt related to these issues. I’ll 
  consolidate them, or at least put them next to each other, so that people 
  won’t see “You can edit conf files via the UI” and then two pages later 
  “pulled editing out of 4x”.
   
  I should have this done later today.  
  
 I’ve committed a cleaned-up set of CHANGES.txt entries to trunk, branch_4x 
 and lucene_solr_4_7. I also added a short description of the current state to 
 the Solr Ref Guide TODO page. Tomorrow I’ll see where a version of this info 
 should go in the Ref Guide.
  
 The 5.0 New Features entries are currently wrong, since they claim 
 creation/editing capabilities that aren’t actually available, since Stefan 
 reverted the UI part of this functionality in SOLR-5539. I left it that way 
 hoping that the situation gets resolved before 5.0 get released.
  
 Stefan, Erick, I’d appreciate it if you could look at the changes I made and 
 help me fix them if I’ve screwed it up.
  
 Trunk changes: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/CHANGES.txt?r1=1570764r2=1570763pathrev=1570764diff_format=h
  
 branch_4x (and lucene_solr_4_7) changes: 
 http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/CHANGES.txt?r1=1570771r2=1570770pathrev=1570771diff_format=h
  
 Thanks,
 Steve
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
 (mailto:dev-unsubscr...@lucene.apache.org)
 For additional commands, e-mail: dev-h...@lucene.apache.org 
 (mailto:dev-h...@lucene.apache.org)

[jira] [Updated] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicate

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

Uwe Schindler updated SOLR-5764:

Attachment: SOLR-5764.patch

This is a patch of the code changes to fix analytics and morphline/mapreduce
tests. This patch also hides the constant to get source home dir, so tests
cannot use it.

The file moves in morphlines are not included.

This patch also removes the copy of src/test-files to build/test-files (which
was a hack to prevent broken test from overriding test-files). The security
manager prevents this, so this is no longer needed.

Key: SOLR-5764
URL: https://issues.apache.org/jira/browse/SOLR-5764
Project: Solr
Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 4.8, 5.0

Attachments: SOLR-5764.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)

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

Uwe Schindler commented on SOLR-5764:
-

I will commit this soon and backport to 4.x. 4.7 will stay as-is.

Key: SOLR-5764
URL: https://issues.apache.org/jira/browse/SOLR-5764
Project: Solr
Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 4.8, 5.0

Attachments: SOLR-5764.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570898 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1570898 ]

SOLR-5764: Fix recently added tests to not use absolute paths to load 
test-files, use SolrTestCaseJ4.getFile() and getResource() instead; fix 
morphlines/map-reduce to not duplicate test resources and fix dependencies 
among them.

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570910 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1570910 ]

Merged revision(s) 1570898 from lucene/dev/trunk:
SOLR-5764: Fix recently added tests to not use absolute paths to load 
test-files, use SolrTestCaseJ4.getFile() and getResource() instead; fix 
morphlines/map-reduce to not duplicate test resources and fix dependencies 
among them.

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-5658) commitWithin does not reflect the new documents added


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

Mark Miller resolved SOLR-5658.
---

Resolution: Fixed

The backcompat issue was moved to SOLR-5658. Resolving this.

 commitWithin does not reflect the new documents added
 -

 Key: SOLR-5658
 URL: https://issues.apache.org/jira/browse/SOLR-5658
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.6, 5.0
Reporter: Varun Thacker
Assignee: Mark Miller
Priority: Critical
 Fix For: 4.7, 5.0, 4.6.1

 Attachments: SOLR-5658.patch, SOLR-5658.patch


 I start 4 nodes using the setup mentioned on - 
 https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud
  
 I added a document using - 
 curl http://localhost:8983/solr/update?commitWithin=1 -H Content-Type: 
 text/xml --data-binary 'adddocfield 
 name=idtestdoc/field/doc/add'
 In Solr 4.5.1 there is 1 soft commit with openSearcher=true and 1 hard commit 
 with openSearcher=false
 In Solr 4.6.x there is there is only one commit hard commit with 
 openSearcher=false
  
 So even after 10 seconds queries on none of the shards reflect the added 
 document. 
 This was also reported on the solr-user list ( 
 http://lucene.472066.n3.nabble.com/Possible-regression-for-Solr-4-6-0-commitWithin-does-not-work-with-replicas-td4106102.html
  )
 Here are the relevant logs 
 Logs from Solr 4.5.1
 Node 1:
 {code}
 420021 [qtp619011445-12] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update params={commitWithin=1} {add=[testdoc]} 0 45
 {code}
  
 Node 2:
 {code}
 119896 [qtp1608701025-10] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update 
 params={distrib.from=http://192.168.1.103:8983/solr/collection1/update.distrib=TOLEADERwt=javabinversion=2}
  {add=[testdoc (1458003295513608192)]} 0 348
 129648 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
 129679 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@e174f70 main
 129680 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener sending requests to Searcher@e174f70 
 main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener done.
 129681 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 [collection1] Registered new searcher Searcher@e174f70 
 main{StandardDirectoryReader(segments_3:11:nrt _2(4.5.1):C1)}
 134648 [commitScheduler-7-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
 134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 SolrDeletionPolicy.onCommit: commits: num=2
   
 commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
  lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_3,generation=3}
   
 commit{dir=NRTCachingDirectory(org.apache.lucene.store.NIOFSDirectory@/Users/varun/solr-4.5.1/node2/solr/collection1/data/index
  lockFactory=org.apache.lucene.store.NativeFSLockFactory@66a394a3; 
 maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_4,generation=4}
 134658 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 newest commit generation = 4
 134660 [commitScheduler-7-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
  {code}
  
 Node 3:
  
 Node 4:
 {code}
 374545 [qtp1608701025-16] INFO  
 org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] 
 webapp=/solr path=/update 
 params={distrib.from=http://192.168.1.103:7574/solr/collection1/update.distrib=FROMLEADERwt=javabinversion=2}
  {add=[testdoc (1458002133233172480)]} 0 20
 384545 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – start 
 commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
 384552 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@36137e08 main
 384553 [commitScheduler-8-thread-1] INFO  
 org.apache.solr.update.UpdateHandler  – end_commit_flush
 384553 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – 
 QuerySenderListener sending

[jira] [Resolved] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicate

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

Uwe Schindler resolved SOLR-5764.
-

Resolution: Fixed

I fixed this for now.

Ideally, we should review the test-resources folder of morphlines-core and
maybe correctly split it up so every module has its own folder with only the
minimum amount of files.

I am not sure if the Maven build works correctly, because I cannot fully test
it: it complains about some missing jersey artifact here. Nevertheless, the
map-reduce and morphlines-cell already depend on morphlines-core with
scope=test, so the shared test-files folder should work correctly.

Key: SOLR-5764
URL: https://issues.apache.org/jira/browse/SOLR-5764
Project: Solr
Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 4.8, 5.0

Attachments: SOLR-5764.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-3854) SolrCloud does not work with https

2014-02-22 Thread ASF subversion and git services (JIRA)


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

Mark Miller commented on SOLR-3854:
---

Thanks [~sdavids]. Sorry for the delayed response, have not been feeling well. 
Unless there is another RC we can discuss getting this into, which seems 
unlikely at this point, we will have to address it in a 4.7.1 or 4.8 release.

bq. That is because the base url is being compared in the clusterstate to grab 
the previously assigned core node name / shard id. 

That sounds like an ugly bug, though I have not looked at the code or patch 
yet. 



 SolrCloud does not work with https
 --

 Key: SOLR-3854
 URL: https://issues.apache.org/jira/browse/SOLR-3854
 Project: Solr
  Issue Type: Bug
Reporter: Sami Siren
Assignee: Mark Miller
 Fix For: 4.7, 5.0

 Attachments: SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, 
 SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, 
 SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, SOLR-3854.patch, 
 SOLR-3854v2.patch, SOLR-3854v3.patch, SOLR-3854v4.patch


 There are a few places in current codebase that assume http is used. This 
 prevents using https when running solr in cloud mode.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570928 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1570928 ]

SOLR-5764: Add workaround to make Maven work (shared test-files does not seem 
to be included when the test-jar dependency is resolved).

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570929 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1570929 ]

Merged revision(s) 1570928 from lucene/dev/trunk:
SOLR-5764: Add workaround to make Maven work (shared test-files does not seem 
to be included when the test-jar dependency is resolved).

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)

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

Uwe Schindler commented on SOLR-5764:
-

[~steve_rowe]: I added a hack into the maven poms. The dependnecy does not seem
to include the shared test-files folder, which is provided by
solr-morphlines-core. solr-morphlines-cell and solr-map-reduce fail to lookup
the resource. Maybe you can fix this by including the test-files folder to the
test artifact.

Key: SOLR-5764
URL: https://issues.apache.org/jira/browse/SOLR-5764
Project: Solr
Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 4.8, 5.0

Attachments: SOLR-5764.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Re: [VOTE] Lucene / Solr 4.7.0 RC4

2014-02-22 Thread Mark Miller

I have simliar feelings to the white list issue (which looks like it did make 
it in). You can still use the feature, it’s a new feature and so no regression, 
and so I’d vote to document the limitation around migrating from http to https 
(you have to start with https without manual work) and address this in a 4.7.1 
or 4.8.

I do think its something we should address if a more serious issue causes a 
respin - it’s a straightforward fix - we should always be using the 
coreNodeName to match state - never the url or address.

- Mark

http://about.me/markrmiller

On Feb 22, 2014, at 8:19 AM, Steve Davids sdav...@gmail.com wrote:

 Hate to bring this up, though it must have gotten lost in the shuffle. When 
 migrating from http - https in SOLR-3854 shards aren’t obtaining their old 
 core node name and resuming their prior assignments. This is because the 
 base_url is being compared instead (which changed) instead of something more 
 constant like the node_name. A patch was attached yesterday: 
 https://issues.apache.org/jira/browse/SOLR-3854?focusedCommentId=13908014page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13908014.
  It is a quick patch that hasn’t really been tested yet, will do so later 
 this evening.
 
 The current work-around would be that if clients want to migrate to https, 
 they will need to shutdown their servers, migrate the cluster state’s 
 base_url from http to https and bring the server back up.
 
 -Steve
 
 On Feb 22, 2014, at 5:46 AM, Simon Willnauer simon.willna...@gmail.com 
 wrote:
 
 Please vote for the forth Release Candidate for Lucene/Solr 4.7.0
 
 you can download it here:
 http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC4-rev1570806/
 or run the smoke tester directly with this commandline (don't forget
 to set JAVA6_HOME etc.):
 
 $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
 http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC4-rev1570806/
 1570806 4.7.0 /tmp/smoke_test_4_7
 
 Smoketester said: SUCCESS!
 
 here is my +1
 
 This RC includes the following fixes compared to RC3
 
 
 r1570798 | noble | 2014-02-22 07:50:02 +0100 (Sat, 22 Feb 2014) | 1 line
 SOLR-3854 urlScheme property should be whitelisted
 
 r1570795 | noble | 2014-02-22 07:42:22 +0100 (Sat, 22 Feb 2014) | 1 line
 SOLR-5762 broke backward compatibility of Javabin format
 
 r1570772 | sarowe | 2014-02-22 01:49:11 +0100 (Sat, 22 Feb 2014) | 1 line
 Fix CHANGES.txt to reflect the twisted evolution and current state of
 the Admin UI Files conf directory File Browser.  (merged branch_4x
 r1570771)
 
 r1570741 | sarowe | 2014-02-21 23:51:47 +0100 (Fri, 21 Feb 2014) | 1 line
 LUCENE-5465: Solr Contrib map-reduce breaks Manifest of all other JAR
 files by adding a broken Main-Class attribute (merged trunk r1570738)
 
 r1570628 | sarowe | 2014-02-21 17:38:59 +0100 (Fri, 21 Feb 2014) | 1 line
 SOLR-5729: intellij config (merge trunk r1570626)
 
 r1570576 | mvg | 2014-02-21 15:06:41 +0100 (Fri, 21 Feb 2014) | 2 lines
 Fixed typo in CHANGES.txt for issue LUCENE-5399 and moved that issue
 under optimizations.
 
 r1570562 | mikemccand | 2014-02-21 13:49:47 +0100 (Fri, 21 Feb 2014) | 1 line
 LUCENE-5461: fix thread hazard in ControlledRealTimeReopenThread
 causing a possible too-long wait time when a thread was waiting for a
 specific generation
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570931 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1570931 ]

SOLR-5764: Make error message of SolrTestCaseJ4.getFile() more readable.

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570932 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1570932 ]

Merged revision(s) 1570931 from lucene/dev/trunk:
SOLR-5764: Make error message of SolrTestCaseJ4.getFile() more readable.

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

solrdispatchfilter error

2014-02-22 Thread Pradeep Pujari

Hi,

I imported solr 4.6 source code int eclipse under windows 8.1 Enterprise. Did 
ant eclipse and improted as a java project and then converted java project to 
Dynamic web project. Copied webcontent folder from solr war 4.6 into my 
project. I am geeting this below exception. I tried some the pointers given in 
the solr wiki page 
https://wiki.apache.org/solr/SolrTomcat#Installing_Solr_instances_under_Tomcat 
, but it did not help

INFO: Starting Servlet Engine: Apache Tomcat/7.0.47
Feb 22, 2014 2:15:28 PM org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter SolrRequestFilter
java.lang.ClassNotFoundException: org.apache.solr.servlet.SolrDispatchFilter
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1702)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1547)
at 
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:532)
at 
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:514)
at 
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:142)
at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:260)
at 
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:107)
at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

Feb 22, 2014 2:15:28 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: Error filterStart
Feb 22, 2014 2:15:28 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: Context [] startup failed due to previous errors
SLF4J: Class path contains multiple SLF4J bindings.

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570937 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1570937 ]

SOLR-5764: More improvements.

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570938 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1570938 ]

Merged revision(s) 1570937 from lucene/dev/trunk:
SOLR-5764: More improvements.

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_51) - Build # 9564 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9564/
Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 43745 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:453: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:57: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:208: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:543: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2329:
 java.net.UnknownHostException: issues.apache.org
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:178)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618)
at 
sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:160)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.protocol.https.HttpsClient.init(HttpsClient.java:275)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:371)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:932)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
at 
org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660)
at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579)
at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)

Total time: 68 minutes 17 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops -XX:+UseG1GC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Updated] (SOLR-4470) Support for basic http auth in internal solr requests

2014-02-22 Thread JIRA


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

Jan Høydahl updated SOLR-4470:
--

Attachment: (was: SOLR-4470.diff)

 Support for basic http auth in internal solr requests
 -

 Key: SOLR-4470
 URL: https://issues.apache.org/jira/browse/SOLR-4470
 Project: Solr
  Issue Type: New Feature
  Components: clients - java, multicore, replication (java), SolrCloud
Affects Versions: 4.0
Reporter: Per Steffensen
Assignee: Jan Høydahl
  Labels: authentication, https, solrclient, solrcloud, ssl
 Fix For: 5.0

 Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
 SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, 
 SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, 
 SOLR-4470_trunk_r1568857.patch


 We want to protect any HTTP-resource (url). We want to require credentials no 
 matter what kind of HTTP-request you make to a Solr-node.
 It can faily easy be acheived as described on 
 http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes 
 also make internal request to other Solr-nodes, and for it to work 
 credentials need to be provided here also.
 Ideally we would like to forward credentials from a particular request to 
 all the internal sub-requests it triggers. E.g. for search and update 
 request.
 But there are also internal requests
 * that only indirectly/asynchronously triggered from outside requests (e.g. 
 shard creation/deletion/etc based on calls to the Collection API)
 * that do not in any way have relation to an outside super-request (e.g. 
 replica synching stuff)
 We would like to aim at a solution where original credentials are 
 forwarded when a request directly/synchronously trigger a subrequest, and 
 fallback to a configured internal credentials for the 
 asynchronous/non-rooted requests.
 In our solution we would aim at only supporting basic http auth, but we would 
 like to make a framework around it, so that not to much refactoring is 
 needed if you later want to make support for other kinds of auth (e.g. digest)
 We will work at a solution but create this JIRA issue early in order to get 
 input/comments from the community as early as possible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-4470) Support for basic http auth in internal solr requests

2014-02-22 Thread JIRA


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

Jan Høydahl updated SOLR-4470:
--

Attachment: SOLR-4470.patch

 Support for basic http auth in internal solr requests
 -

 Key: SOLR-4470
 URL: https://issues.apache.org/jira/browse/SOLR-4470
 Project: Solr
  Issue Type: New Feature
  Components: clients - java, multicore, replication (java), SolrCloud
Affects Versions: 4.0
Reporter: Per Steffensen
Assignee: Jan Høydahl
  Labels: authentication, https, solrclient, solrcloud, ssl
 Fix For: 5.0

 Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 
 SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, 
 SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, 
 SOLR-4470_trunk_r1568857.patch


 We want to protect any HTTP-resource (url). We want to require credentials no 
 matter what kind of HTTP-request you make to a Solr-node.
 It can faily easy be acheived as described on 
 http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes 
 also make internal request to other Solr-nodes, and for it to work 
 credentials need to be provided here also.
 Ideally we would like to forward credentials from a particular request to 
 all the internal sub-requests it triggers. E.g. for search and update 
 request.
 But there are also internal requests
 * that only indirectly/asynchronously triggered from outside requests (e.g. 
 shard creation/deletion/etc based on calls to the Collection API)
 * that do not in any way have relation to an outside super-request (e.g. 
 replica synching stuff)
 We would like to aim at a solution where original credentials are 
 forwarded when a request directly/synchronously trigger a subrequest, and 
 fallback to a configured internal credentials for the 
 asynchronous/non-rooted requests.
 In our solution we would aim at only supporting basic http auth, but we would 
 like to make a framework around it, so that not to much refactoring is 
 needed if you later want to make support for other kinds of auth (e.g. digest)
 We will work at a solution but create this JIRA issue early in order to get 
 input/comments from the community as early as possible.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-5605) MapReduceIndexerTool fails in some locales -- seen in random failures of MapReduceIndexerToolArgumentParserTest


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

Mark Miller resolved SOLR-5605.
---

Resolution: Fixed

What I meant is: have you looked at it with the updated code that led to 
resolving this issue.

The reason I ask is that the help appeared to be displaying fine for me in my 
testing.

In any case, if this is indeed an issue, it will need a new JIRA for a possible 
4.7.1 or 4.8.

 MapReduceIndexerTool fails in some locales -- seen in random failures of 
 MapReduceIndexerToolArgumentParserTest
 ---

 Key: SOLR-5605
 URL: https://issues.apache.org/jira/browse/SOLR-5605
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Mark Miller
 Fix For: 4.7, 5.0


 I noticed a randomized failure in MapReduceIndexerToolArgumentParserTest 
 which is reproducible with any seed -- all that matters is the locale.
 The problem sounded familiar, and a quick search verified that jenkins has in 
 fact hit this a couple of times in the past -- Uwe commented on the list that 
 this is due to a real problem in one of the third-party dependencies (that 
 does the argument parsing) that will affect usage on some systems.
 If working around the bug in the arg parsing lib isn't feasible, 
 MapReduceIndexerTool should fail cleanly if the locale isn't one we know is 
 supported



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5758) need ref guide doc on building indexes with mapreduce (morphlines-cell contrib)

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

Mark Miller commented on SOLR-5758:
---

As a start, here is the help text for the MapReduceIndexerTool:

{noformat}
usage: hadoop [GenericOptions]... jar solr-map-reduce-*.jar
[--help] --output-dir HDFS_URI [--input-list URI] --morphline-file FILE
[--morphline-id STRING] [--update-conflict-resolver FQCN] [--mappers INTEGER]
[--reducers INTEGER] [--max-segments INTEGER] [--fair-scheduler-pool STRING]
[--dry-run] [--log4j FILE] [--verbose] [--show-non-solr-cloud]
[--zk-host STRING] [--go-live] [--collection STRING] [--go-live-threads
INTEGER] [HDFS_URI [HDFS_URI ...]]

MapReduce batch job driver that takes a morphline and creates a set of Solr
index shards from a set of input files and writes the indexes into HDFS,
in a flexible, scalable and fault-tolerant manner. It also supports merging
the output shards into a set of live customer facing Solr servers, typically a
SolrCloud. The program proceeds in several consecutive MapReduce based phases,
as follows:

1) Randomization phase: This (parallel) phase randomizes the list of input
files in order to spread indexing load more evenly among the mappers of the
subsequent phase.

2) Mapper phase: This (parallel) phase takes the input files, extracts the
relevant content, transforms it and hands SolrInputDocuments to a set of
reducers. The ETL functionality is flexible and customizable using chains of
arbitrary morphline commands that pipe records from one transformation command
to
another. Commands to parse and transform a set of standard data formats such as
Avro, CSV, Text, HTML, XML, PDF, Word, Excel, etc. are provided out of the
box, and additional custom commands and parsers for additional file or data
formats can be added as morphline plugins. This is done by implementing a simple
Java interface that consumes a record (e.g. a file in the form of an
InputStream plus some headers plus contextual metadata) and generates as output
zero or more records. Any kind of data format can be indexed and any Solr
documents for any kind of Solr schema can be generated, and any custom ETL
logic can be
registered and executed.
Record fields, including MIME types, can also explicitly be passed by force
from the CLI to the morphline, for example: hadoop ... -D
morphlineField._attachment_mimetype=text/csv

3) Reducer phase: This (parallel) phase loads the mapper's SolrInputDocuments
into one EmbeddedSolrServer per reducer. Each such reducer and Solr server can
be seen as a (micro) shard. The Solr servers store their data in HDFS.

4) Mapper-only merge phase: This (parallel) phase merges the set of reducer
shards into the number of solr shards expected by the user, using a mapper-only
job. This phase is omitted if the number of shards is already equal to the
number of shards expected by the user.

5) Go-live phase: This optional (parallel) phase merges the output shards of
the previous phase into a set of live customer facing Solr servers, typically a
SolrCloud. If this phase is omitted you can explicitly point each Solr server
to one of the HDFS output shard directories.

Fault Tolerance: Mapper and reducer task attempts are retried on failure per
the standard MapReduce semantics. On program startup all data in the
--output-dir is deleted if that output directory already exists. If the whole
job fails you can retry simply by rerunning the program again using the same
arguments.

positional arguments:
HDFS_URI HDFS URI of file or directory tree to index. (default:
[])

optional arguments:
--help, -help, -h Show this help message and exit
--input-list URI Local URI or HDFS URI of a UTF-8 encoded file
containing a list of HDFS URIs to index, one URI per line in the file. If '-'
is specified, URIs are read from the standard input. Multiple --input-list
arguments can be specified.
--morphline-id STRING The identifier of the morphline that shall be executed
within the morphline config file specified by --morphline-file. If the
--morphline-id option is ommitted the first (i.e. top-most) morphline within
the config file is used. Example: morphline1
--update-conflict-resolver FQCN
Fully qualified class name of a Java class that
implements the UpdateConflictResolver interface. This enables deduplication and
ordering of a series of document updates for the same unique document key.
For example, a MapReduce batch job might index multiple files in the same job
where
some of the files contain old and new versions of the
very same document, using the same unique document key.
Typically, implementations of this interface forbid
collisions by throwing an exception, or ignore all but the most

[jira] [Commented] (SOLR-5758) need ref guide doc on building indexes with mapreduce (morphlines-cell contrib)


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

Mark Miller commented on SOLR-5758:
---

Kite Morphlines documentation: http://kitesdk.org/docs/current/kite-morphlines/

 need ref guide doc on building indexes with mapreduce (morphlines-cell 
 contrib)
 ---

 Key: SOLR-5758
 URL: https://issues.apache.org/jira/browse/SOLR-5758
 Project: Solr
  Issue Type: Task
  Components: documentation
Reporter: Hoss Man
Assignee: Mark Miller
 Fix For: 4.8


 This is marked experimental for 4.7, but we should have a section on it in 
 the ref guide in 4.8



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-fcs-b129) - Build # 9457 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9457/
Java: 32bit/jdk1.8.0-fcs-b129 -client -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 49866 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:459: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:398: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:87: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:185: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* ./solr/contrib/morphlines-core/src/test-files/morphlines-core.marker
* ./solr/contrib/morphlines-core/src/test-files/test-documents/cars.csv
* ./solr/contrib/morphlines-core/src/test-files/test-documents/complex.mbox
* ./solr/contrib/morphlines-core/src/test-files/test-documents/email.eml
* ./solr/contrib/morphlines-core/src/test-files/test-documents/rsstest.rss
* 
./solr/contrib/morphlines-core/src/test-files/test-documents/sample-statuses-20120906-141433
* ./solr/contrib/morphlines-core/src/test-files/test-documents/testEMLX.emlx
* ./solr/contrib/morphlines-core/src/test-files/test-documents/testRFC822
* 
./solr/contrib/morphlines-core/src/test-files/test-documents/testRTFVarious.rtf
* ./solr/contrib/morphlines-core/src/test-files/test-documents/testSVG.svg
* 
./solr/contrib/morphlines-core/src/test-files/test-morphlines/loadSolrBasic.conf
* 
./solr/contrib/morphlines-core/src/test-files/test-morphlines/solrCellDocumentTypes.conf
* 
./solr/contrib/morphlines-core/src/test-files/test-morphlines/solrCellJPGCompressed.conf
* ./solr/contrib/morphlines-core/src/test-files/test-morphlines/solrCellXML.conf
* 
./solr/contrib/morphlines-core/src/test-files/test-morphlines/tokenizeText.conf
* 
./solr/contrib/morphlines-core/src/test-files/test-morphlines/tutorialReadAvroContainer.conf

Total time: 64 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.8.0-fcs-b129 -client -XX:+UseSerialGC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Created] (SOLR-5765) Update to SLF4J 1.7.6.

Mark Miller created SOLR-5765:
-

 Summary: Update to SLF4J 1.7.6.
 Key: SOLR-5765
 URL: https://issues.apache.org/jira/browse/SOLR-5765
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor


We are getting fairly behind, we should update and pick up the latest bug fixes 
and improvements.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5765) Update to SLF4J 1.7.6.


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

Mark Miller updated SOLR-5765:
--

Fix Version/s: 5.0
   4.8

 Update to SLF4J 1.7.6.
 --

 Key: SOLR-5765
 URL: https://issues.apache.org/jira/browse/SOLR-5765
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.8, 5.0


 We are getting fairly behind, we should update and pick up the latest bug 
 fixes and improvements.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5765) Update to SLF4J 1.7.6.

2014-02-22 Thread ASF subversion and git services (JIRA)


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

Mark Miller commented on SOLR-5765:
---

One of the release note comments for 1.7.5: Given the significance of these 
performance improvements, users are highly encouraged to migrate to SLF4J 
version 1.7.5 or later.

 Update to SLF4J 1.7.6.
 --

 Key: SOLR-5765
 URL: https://issues.apache.org/jira/browse/SOLR-5765
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.8, 5.0


 We are getting fairly behind, we should update and pick up the latest bug 
 fixes and improvements.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5765) Update to SLF4J 1.7.6.


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

ASF subversion and git services commented on SOLR-5765:
---

Commit 1570951 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1570951 ]

SOLR-5765: Update to SLF4J 1.7.6.

 Update to SLF4J 1.7.6.
 --

 Key: SOLR-5765
 URL: https://issues.apache.org/jira/browse/SOLR-5765
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.8, 5.0


 We are getting fairly behind, we should update and pick up the latest bug 
 fixes and improvements.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5765) Update to SLF4J 1.7.6.

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5765:
---

Commit 1570952 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1570952 ]

SOLR-5765: Update to SLF4J 1.7.6.

 Update to SLF4J 1.7.6.
 --

 Key: SOLR-5765
 URL: https://issues.apache.org/jira/browse/SOLR-5765
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.8, 5.0


 We are getting fairly behind, we should update and pick up the latest bug 
 fixes and improvements.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5765) Update to SLF4J 1.7.6.

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5765:
---

Commit 1570953 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1570953 ]

SOLR-5765: Update jar checksums.

 Update to SLF4J 1.7.6.
 --

 Key: SOLR-5765
 URL: https://issues.apache.org/jira/browse/SOLR-5765
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.8, 5.0


 We are getting fairly behind, we should update and pick up the latest bug 
 fixes and improvements.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5765) Update to SLF4J 1.7.6.

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5765:
---

Commit 1570954 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1570954 ]

SOLR-5765: Update jar checksums.

 Update to SLF4J 1.7.6.
 --

 Key: SOLR-5765
 URL: https://issues.apache.org/jira/browse/SOLR-5765
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.8, 5.0


 We are getting fairly behind, we should update and pick up the latest bug 
 fixes and improvements.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570955 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1570955 ]

SOLR-5764: Set eol-style on test resources

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (LUCENE-5466) query is always null in countDocsWithClass() of SimpleNaiveBayesClassifier

2014-02-22 Thread Koji Sekiguchi (JIRA)

Koji Sekiguchi created LUCENE-5466:
--

 Summary: query is always null in countDocsWithClass() of 
SimpleNaiveBayesClassifier
 Key: LUCENE-5466
 URL: https://issues.apache.org/jira/browse/LUCENE-5466
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/classification
Reporter: Koji Sekiguchi
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (LUCENE-5466) query is always null in countDocsWithClass() of SimpleNaiveBayesClassifier

2014-02-22 Thread Koji Sekiguchi (JIRA)


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

Koji Sekiguchi updated LUCENE-5466:
---

Attachment: LUCENE-5466.patch

I think query must be set before calling countDocsWithClass() in train() method.

 query is always null in countDocsWithClass() of SimpleNaiveBayesClassifier
 --

 Key: LUCENE-5466
 URL: https://issues.apache.org/jira/browse/LUCENE-5466
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/classification
Reporter: Koji Sekiguchi
Priority: Trivial
 Attachments: LUCENE-5466.patch






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5764) Fix recently added tests to not use absolute paths to load resources, use SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce to not duplicat

2014-02-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-5764:
---

Commit 1570960 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1570960 ]

SOLR-5764: Set eol-style on test resources

 Fix recently added tests to *not* use absolute paths to load resources, use 
 SolrTestCaseJ4.getFile() and getResource() instead; fix morphlines/map-reduce 
 to not duplicate test resources and fix dependencies among them
 -

 Key: SOLR-5764
 URL: https://issues.apache.org/jira/browse/SOLR-5764
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 4.8, 5.0

 Attachments: SOLR-5764.patch


 Tests that were recently added have the problems that some of them were using 
 {{ExternalPaths.SOURCE_HOME}} and adding the absolute location of modules. 
 This makes it impossible to move modules around or run them standalone.
 This issue fixes those tests to use {{SolrTestCaseJ4.getFile()}} or a simple 
 openResourceAsStream from classpath, because all {{test-files}} are located 
 in classpath. {{ExternalPaths.SOURCE_HOME}} will be hidden (private) so 
 nothing can use it anymore - so no new tests should appear using them again.
 While doing this, I recognized that the recently added morphlines and 
 mapreduce contribs are duplicating modified solr example folders into their 
 test-files folder, while morphlines-core was referring from inside the tests 
 to map-reduce/test-files (ignoring the whole megabytes of test-files of 
 morphlines!!! Easy to see, because the config files in it were just broken 
 and referring to non-existent classes). This is the reverse of the natural 
 dependency, where map-reduce uses morphlines as dep.
 The fix here is to completely delete/empty the test-files folders of 
 map-reduce and morphlines-cell and let those reuse the one from 
 morphlines-core. Morphlines-core is now the only source folder for 
 test-files, shared by all three contribs. Its contents are now the previous 
 map-reduce/test-files folder.
 I will provide a patch with the code changes, but the cleanup of morphlines 
 test-files cannot be described here, it is too crazy. I will just heavy 
 commit the changes, sorry!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_60-ea-b04) - Build # 9458 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9458/
Java: 32bit/jdk1.7.0_60-ea-b04 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 50658 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:459: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:398: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:87: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:185: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* ./solr/licenses/jcl-over-slf4j-1.7.6.jar.sha1
* ./solr/licenses/jul-to-slf4j-1.7.6.jar.sha1
* ./solr/licenses/slf4j-api-1.7.6.jar.sha1
* ./solr/licenses/slf4j-log4j12-1.7.6.jar.sha1

Total time: 63 minutes 37 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.7.0_60-ea-b04 -client -XX:+UseConcMarkSweepGC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1358 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1358/
Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 16913 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/contrib/solr-map-reduce/test/temp/junit4-J0-20140223_045252_470.syserr
   [junit4]  JVM J0: stderr (verbatim) 
   [junit4] 2014-02-23 04:53:08.888 java[317:650f] Unable to load realm info 
from SCDynamicStore
   [junit4]  JVM J0: EOF 

[...truncated 40465 lines...]
BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:453: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:392: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/extra-targets.xml:87: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/extra-targets.xml:185: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* ./solr/licenses/jcl-over-slf4j-1.7.6.jar.sha1
* ./solr/licenses/jul-to-slf4j-1.7.6.jar.sha1
* ./solr/licenses/slf4j-api-1.7.6.jar.sha1
* ./solr/licenses/slf4j-log4j12-1.7.6.jar.sha1

Total time: 131 minutes 4 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops 
-XX:+UseConcMarkSweepGC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

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

2014-02-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/597/

3 tests failed.
REGRESSION:  
org.apache.solr.morphlines.cell.SolrCellMorphlineTest.testSolrCellDocumentTypes2

Error Message:
key:ignored_creation_date expected:[2007-10-01T16:13:56Z] but was:[]

Stack Trace:
java.lang.AssertionError: key:ignored_creation_date 
expected:[2007-10-01T16:13:56Z] but was:[]
at 
__randomizedtesting.SeedInfo.seed([B5AC34D42478F5EC:3E2C8F34238E6612]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at 
org.apache.solr.morphlines.solr.AbstractSolrMorphlineTestBase.testDocumentTypesInternal(AbstractSolrMorphlineTestBase.java:165)
at 
org.apache.solr.morphlines.cell.SolrCellMorphlineTest.testSolrCellDocumentTypes2(SolrCellMorphlineTest.java:255)


REGRESSION:  org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:19127/collection1, 
https://127.0.0.1:25706/collection1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:19127/collection1, 
https://127.0.0.1:25706/collection1]
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:495)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:302)
at 
org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:635)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90)
at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1427)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:563)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:545)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:524)
at 
org.apache.solr.cloud.BasicDistributedZk2Test.brindDownShardIndexSomeDocsAndRecover(BasicDistributedZk2Test.java:296)
at 
org.apache.solr.cloud.BasicDistributedZk2Test.doTest(BasicDistributedZk2Test.java:113)


REGRESSION:  org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch

Error Message:
Timeout occured while waiting response from server at: 
https://127.0.0.1:13139/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:13139/collection1
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:146)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:883)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:840)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:94)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:682)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at

[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_51) - Build # 9459 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9459/
Java: 64bit/jdk1.7.0_51 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
REGRESSION:  
org.apache.solr.client.solrj.impl.CloudSolrServerTest.testDistribSearch

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:52745 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:52745 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([981CBE171E5ADC35:19FA300F6905BC09]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:148)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:99)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:94)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:85)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:89)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:83)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:70)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:200)
at 
org.apache.solr.client.solrj.impl.CloudSolrServerTest.setUp(CloudSolrServerTest.java:77)
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:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:771)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at

Solr Reference Guide pages; turn off comments?

2014-02-22 Thread David Smiley (@MITRE.org)

I was just thinking about the comments feature of the Solr Reference Guide
(e.g. Confluence). On one hand it's a nice feature that also allows
non-committers to be involved. But, over time, couldn't it easily get out
of hand (as-implemented)? That is... as a series of ever-growing comments
that make the page longer and longer, it seems it *could* become a bad thing
over time. It isn't a problem now on the pages I've seen. It's easy to
falsely make a like-kind comparison to JIRA issues but there is a big
difference because JIRA issues become closed! A reference guide page will
likely live forever. Perhaps my concern could be addressed in a
presentational way, like if you consider that MediaWiki has a separate
screen/page for this kind of thing; and as such I think is more manageable
then growing the original page forever. I checked for a Confluence plugin
for that but turned up nothing obvious in Atlassian's plugin marketplace.

So I may have commented on a page in the past but I have no intention in
adding any more. If I have a comment; I'll make it on the dev list.

~ David

-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Reference-Guide-pages-turn-off-comments-tp4119062.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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-fcs-b129) - Build # 9567 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9567/
Java: 32bit/jdk1.8.0-fcs-b129 -client -XX:+UseParallelGC

1 tests failed.
REGRESSION:  
org.apache.solr.client.solrj.impl.CloudSolrServerTest.testDistribSearch

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:51751 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:51751 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([58C668EF604E5025:D920E6F717113019]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:148)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:99)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:94)
at 
org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:85)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:89)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:83)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:70)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:200)
at 
org.apache.solr.client.solrj.impl.CloudSolrServerTest.setUp(CloudSolrServerTest.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:771)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at

[JENKINS] Lucene-Solr-Tests-4.x-Java7 - Build # 1909 - Still Failing

2014-02-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java7/1909/

All tests passed

Build Log:
[...truncated 28657 lines...]
check-licenses:
 [echo] License check under: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/solr
 [licenses] MISSING sha1 checksum file for: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/solr/example/lib/ext/jcl-over-slf4j-1.6.6.jar
 [licenses] EXPECTED sha1 checksum file : 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/solr/licenses/jcl-over-slf4j-1.6.6.jar.sha1

 [licenses] MISSING sha1 checksum file for: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/solr/example/lib/ext/jul-to-slf4j-1.6.6.jar
 [licenses] EXPECTED sha1 checksum file : 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/solr/licenses/jul-to-slf4j-1.6.6.jar.sha1
 [licenses] MISSING sha1 checksum file for: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/solr/example/lib/ext/slf4j-api-1.6.6.jar
 [licenses] EXPECTED sha1 checksum file : 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/solr/licenses/slf4j-api-1.6.6.jar.sha1

[...truncated 3 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/build.xml:459:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/build.xml:64:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/solr/build.xml:254:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/tools/custom-tasks.xml:62:
 License check failed. Check the logs.

Total time: 108 minutes 22 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-fcs-b129) - Build # 9460 - Still Failing!