date:20130626


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

Yonik Seeley commented on SOLR-4926:


So one thing I see is that when the old IndexWriter is closed, a new segment 
file is written out.

{code}
  2 58339 T257 C69 P58203 oasu.DefaultSolrCoreState.newIndexWriter Closing old 
IndexWriter... core=collection1 
dir=org.apache.lucene.store.MMapDirectory@/opt/code/lusolr_clean5/solr/build/solr-core/test/J0/org.apache.solr.cloud.ChaosMonkeySafeLeaderTest-1372252751336/jetty12/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@42062bad
  2 58341 T257 C69 P58203 oasu.DefaultSolrCoreState.newIndexWriter 
PREFILES=[_0.fdx, segments_1, _0.cfs, _0.si, _0.cfe, _0.fdt, segments.gen, 
segments_4, _0_1.del, write.lock]


  2 58622 T257 C69 P58203 oasc.SolrDeletionPolicy.onCommit 
SolrDeletionPolicy.onCommit: commits DEBUG_INFO: num=2
  2
commit{dir=/opt/code/lusolr_clean5/solr/build/solr-core/test/J0/org.apache.solr.cloud.ChaosMonkeySafeLeaderTest-1372252751336/jetty12/index,segFN=segments_1,generation=1,filenam
es=[segments_1]}
  2
commit{dir=/opt/code/lusolr_clean5/solr/build/solr-core/test/J0/org.apache.solr.cloud.ChaosMonkeySafeLeaderTest-1372252751336/jetty12/index,segFN=segments_2,generation=2,filenam
es=[_0.cfs, _0.cfe, _0_1.del, segments_2, _0.si]}


  2 58630 T257 C69 P58203 oasu.DefaultSolrCoreState.newIndexWriter 
POSTFILES=[segments_2, _0.cfs, _0.si, _0.cfe, segments.gen, segments_4, 
_0_1.del]

{code}

It looks like this new segments file actually references all of the files we 
just replicated, which is of course wrong!


 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.


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

Mark Miller commented on SOLR-4926:
---

Cool - this fits what I am seeing as well. I also checked to see that you could 
open a writer on the index we replicated and you can no problem. I was 
struggling to find what could cause the corruption from there - was suspecting 
the copy to the other dir somehow, but the writer close makes a lot of sense.

And explains the mysterious segments_2 file when I only expected segments_1 and 
segments_3.

 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: Where to aim a patch

2013-06-26 Thread Michael McCandless

On Thu, Jun 13, 2013 at 11:56 AM, Michael McCandless
luc...@mikemccandless.com wrote:
 On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley yo...@lucidworks.com wrote:

 IMO, patches should normally be aimed at trunk and backported.
 svn merge tends to make a mess of the target (mergeproperties
 updated so you can't tell at a glance what files a patch actually
 changed), and in general we've tried to keep trunk clean by merging
 from trunk instead of to trunk.

 Is this really true anymore, with latest svn clients (1.7.x)?

 I had always assumed devs are free to merge in either direction ...
 whatever their preference is.

As far as I can tell it's fine from SVN's standpoint to merge 4.x -
trunk, at least using SVN 1.7.

I just merged a few changes in that direction and I see no difference
in the number of svn props changed, vs when I commit first to trunk
and then merge to 4.x.

So I think net/net we are free to work in whatever direction we
prefer.  We shouldn't let our source control tools dictate our dev.

Mike McCandless

http://blog.mikemccandless.com

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

[jira] [Commented] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.


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

Yonik Seeley commented on SOLR-4926:


OK, looks like the close of the old IW is actually changing some of the segment 
files (the number in parens is the file size).
Now the question is why...

{code}
  2 57648 T256 C30 P58775 oasu.DefaultSolrCoreState.showFiles PREFILES 
_0.cfe(266)_0.cfs(4375)_0.fdt(0)_0.fdx(0)_0.si(239)_0_1.del(32)segments.gen(20)segments_1(45)segments_4(99)write.lock(0)

  2 57887 T256 C30 P58775 oasu.DefaultSolrCoreState.showFiles POSTFILES 
_0.cfe(266)_0.cfs(2993)_0.si(239)_0_1.del(31)segments.gen(20)segments_2(70)segments_4(99)
{code}


 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.

Yonik Seeley created LUCENE-5079:


 Summary: allow IndexWriter user to tell if there are uncommitted 
changes.
 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley


IndexWriter already currently tracks if there are uncommitted changes.  We 
should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: Where to aim a patch

2013-06-26 Thread Robert Muir

On Wed, Jun 26, 2013 at 10:30 AM, Michael McCandless 
luc...@mikemccandless.com wrote:

 On Thu, Jun 13, 2013 at 11:56 AM, Michael McCandless
 luc...@mikemccandless.com wrote:
  On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley yo...@lucidworks.com
 wrote:
 
  IMO, patches should normally be aimed at trunk and backported.
  svn merge tends to make a mess of the target (mergeproperties
  updated so you can't tell at a glance what files a patch actually
  changed), and in general we've tried to keep trunk clean by merging
  from trunk instead of to trunk.
 
  Is this really true anymore, with latest svn clients (1.7.x)?
 
  I had always assumed devs are free to merge in either direction ...
  whatever their preference is.

 As far as I can tell it's fine from SVN's standpoint to merge 4.x -
 trunk, at least using SVN 1.7.

 I just merged a few changes in that direction and I see no difference
 in the number of svn props changed, vs when I commit first to trunk
 and then merge to 4.x.

 So I think net/net we are free to work in whatever direction we
 prefer.  We shouldn't let our source control tools dictate our dev.


One thing to think about is if you develop on trunk and forget to merge to
4.x, thats ok. the other way around is bad though, it basically creates an
instant regression.

So I'm a little worried about this. I think development should be against
trunk!

[jira] [Commented] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.


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

Yonik Seeley commented on SOLR-4926:


Running with a local modification that does a commit at the start of snappuller 
(as well as getting the latest commit point from the deletion policy).  
Crossing my fingers... 12 successes in a row so far.

 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.


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

Yonik Seeley updated LUCENE-5079:
-

Attachment: LUCENE-5079.patch

Simple patch adding IndexWriter.hasUncommittedChanges()

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.


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

Mark Miller updated SOLR-4926:
--

Attachment: SOLR-4926.patch

I have this competing approach attached - all tests pass and my zkrecoverytest 
loop is holding up pretty well (22 passes so far)

 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4

 Attachments: SOLR-4926.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.

2013-06-26 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-5079:


+1

I think the test case comment // this will be true because a commit will 
create a new segment should instead say // this will be true because a commit 
will create an empty index?

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.


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

Yonik Seeley commented on SOLR-4926:


bq. I have this competing approach attached 

Yeah, I like the rollback right before... safer in the event that somehow the 
IW acquires more changes.  I was initially worried about code that uses the IW 
to reopen the reader, but that code (openSearcher) doesn't force open a writer 
and has a fallback to reopen on the reader.

I'll start looping the chaos test with your patch and see how it goes.

 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4

 Attachments: SOLR-4926.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.


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

Uwe Schindler commented on LUCENE-5079:
---

Do we need synchonization here? - I have not looked at the code, just want to 
be sure!

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-2526) Grouping on multiple fields

2013-06-26 Thread yuanyun.cn (JIRA)


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

yuanyun.cn commented on SOLR-2526:
--

We find this jira and https://issues.apache.org/jira/browse/SOLR-2553 - Nested 
Field Collapsing is very useful for us.
Any plan to implement this.
Thanks...

 Grouping on multiple fields
 ---

 Key: SOLR-2526
 URL: https://issues.apache.org/jira/browse/SOLR-2526
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.0-ALPHA
Reporter: Arian Karbasi
Priority: Minor

 Grouping on multiple fields and/or ranges should be an option (X,Y) 
 groupings.   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-2553) Nested Field Collapsing

2013-06-26 Thread yuanyun.cn (JIRA)


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

yuanyun.cn commented on SOLR-2553:
--

We find this jira and https://issues.apache.org/jira/browse/SOLR-2526 - 
Grouping on multiple fields is very useful for us.
Any plan to implement this?
Thanks...

 Nested Field Collapsing
 ---

 Key: SOLR-2553
 URL: https://issues.apache.org/jira/browse/SOLR-2553
 Project: Solr
  Issue Type: Improvement
  Components: SearchComponents - other
Reporter: Martijn Laarman

 Currently specifying grouping on multiple fields returns multiple datasets. 
 It would be nice if Solr supported cascading / nested grouping by applying 
 the first group over the entire result set, the next over each group and so 
 forth and so forth. 
 Even if limited to supporting nesting grouping 2 levels deep would cover alot 
 of use cases. 
 group.field=locationgroup.field=type
 -Location X
 ---Type 1
 -documents
 ---Type 2
 documents
 -Location Y
 ---Type 1
 documents
 ---Type 2
 documents
 instead of 
 -Location X
 -- documents
 -Location Y
 --documents
 -Type 1
 --documents
 -Type2
 --documents

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [Solr Wiki] Update of AnalyzersTokenizersTokenFilters by ErikHatcher

2013-06-26 Thread Jack Krupansky

Doc bug: solr.PatternCaptureGroupTokenFilter s.b. 
solr.PatternCaptureGroupTokenFilterFactory


Both the wiki and the Javadoc have the same issue.

Also, I just happened to notice that there is no unit test for the factory, 
unlike other filter factories.


-- Jack Krupansky

-Original Message- 
From: Apache Wiki

Sent: Tuesday, June 25, 2013 10:48 AM
To: Apache Wiki
Subject: [Solr Wiki] Update of AnalyzersTokenizersTokenFilters by 
ErikHatcher


Dear Wiki user,

You have subscribed to a wiki page or wiki category on Solr Wiki for 
change notification.


The AnalyzersTokenizersTokenFilters page has been changed by ErikHatcher:
https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters?action=diffrev1=146rev2=147

Comment:
added PatternCaptureGroupFilterFactory

  . Example: ` Kittens!   , Duck == Kittens!, Duck`.

 Optionally, the updateOffsets attribute will update the start and end 
position offsets.

+
+ Anchor(PatternCaptureGroupFilter)
+
+ === solr.PatternCaptureGroupFilterFactory ===
+ ! [[Solr4.4]]
+
+ Emits tokens for each capture group in a regular expression
+
+ For example, the following definition will tokenize the input text of 
http://www.foo.com/index; into http://www.foo.com; and www.foo.com.

+
+ {{{
+fieldType name=url_base class=solr.TextField 
positionIncrementGap=100

+  analyzer
+tokenizer class=solr.KeywordTokenizerFactory
+filter class=solr.PatternCaptureGroupTokenFilter 
pattern=(https?://([a-zA-Z\-_0-9.]+)) preserve_original=false

+  /analyzer
+/fieldType
+ }}}
+
+ If none of the patterns match, or if preserve_original is true, the 
original token will also be emitted.

+

 === solr.PatternReplaceFilterFactory ===
 Like the !PatternReplaceCharFilterFactory, but operates post-tokenization. 
See When to use a Char Filter vs. a Token Filter above. 



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

[jira] [Commented] (SOLR-2526) Grouping on multiple fields

2013-06-26 Thread Jean-Sebastien Vachon (JIRA)


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

Jean-Sebastien Vachon commented on SOLR-2526:
-

This feature is very important to us at Wanted Technologies. The lack of this 
feature actually delays our complete migration from SphinxSearch to Solr.

 Grouping on multiple fields
 ---

 Key: SOLR-2526
 URL: https://issues.apache.org/jira/browse/SOLR-2526
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 4.0-ALPHA
Reporter: Arian Karbasi
Priority: Minor

 Grouping on multiple fields and/or ranges should be an option (X,Y) 
 groupings.   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4921) Support for Adding Documents via the Solr UI

2013-06-26 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll resolved SOLR-4921.
---

   Resolution: Fixed
Fix Version/s: 5.0

 Support for Adding Documents via the Solr UI
 

 Key: SOLR-4921
 URL: https://issues.apache.org/jira/browse/SOLR-4921
 Project: Solr
  Issue Type: New Feature
  Components: web gui
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 5.0, 4.4

 Attachments: SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, 
 SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, 
 SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, 
 SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, 
 SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, 
 SOLR-4921.patch


 For demos and prototyping, it would be nice if we could add documents via the 
 admin UI.
 Various things to support:
 1. Uploading XML, JSON, CSV, etc.
 2. Optionally also do file upload

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Java 8 feature complete

2013-06-26 Thread Uwe Schindler

Hi all,

I just installed JDK 8 b94 on the policeman Jenkins server. According to Mark 
Reinhold this is the feature complete version of JDK 8, see 
http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-June/002686.html. Now it 
is time for extensive bug hunting! The release candidates will appear end of 
the year latest (hopefully). At this time we should really fix all test in Solr 
that constantly fail with Java 8. I deactivated them a while ago with an 
assumption (using Constants).

Uwe

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




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

[jira] [Commented] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.


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

Yonik Seeley commented on LUCENE-5079:
--

bq. Do we need synchonization here?

Perhaps just for the fact that the JMM doesn't guarantee we see the 
non-volatile long atomically?
We could just make lastCommitChangeCount volatile I guess...


 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.

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

Yonik Seeley edited comment on LUCENE-5079 at 6/26/13 5:16 PM:
---

bq. Do we need synchonization here?

Perhaps just for the fact that the JMM doesn't guarantee we see the
non-volatile long atomically?
We could just make lastCommitChangeCount volatile I guess...

edit: Actually, it depends on the exact semantics we're looking for. I guess
I'll go with synchronized(this) for now for the greater safety.

was (Author: ysee...@gmail.com):
bq. Do we need synchonization here?

Perhaps just for the fact that the JMM doesn't guarantee we see the
non-volatile long atomically?
We could just make lastCommitChangeCount volatile I guess...

allow IndexWriter user to tell if there are uncommitted changes.

Key: LUCENE-5079
URL: https://issues.apache.org/jira/browse/LUCENE-5079
Project: Lucene - Core
Issue Type: Improvement
Reporter: Yonik Seeley
Attachments: LUCENE-5079.patch

IndexWriter already currently tracks if there are uncommitted changes. We
should expose this somehow... perhaps a boolean hasUncommittedChanges()?

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

Re: [Solr Wiki] Update of AnalyzersTokenizersTokenFilters by ErikHatcher

2013-06-26 Thread Jack Krupansky


Sigh... make that solr.PatternCaptureGroupFilterFactory

-- Jack Krupansky

-Original Message- 
From: Jack Krupansky

Sent: Wednesday, June 26, 2013 12:35 PM
To: dev@lucene.apache.org
Subject: Re: [Solr Wiki] Update of AnalyzersTokenizersTokenFilters by 
ErikHatcher


Doc bug: solr.PatternCaptureGroupTokenFilter s.b.
solr.PatternCaptureGroupTokenFilterFactory

Both the wiki and the Javadoc have the same issue.

Also, I just happened to notice that there is no unit test for the factory,
unlike other filter factories.

-- Jack Krupansky

-Original Message- 
From: Apache Wiki

Sent: Tuesday, June 25, 2013 10:48 AM
To: Apache Wiki
Subject: [Solr Wiki] Update of AnalyzersTokenizersTokenFilters by
ErikHatcher

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Solr Wiki for
change notification.

The AnalyzersTokenizersTokenFilters page has been changed by ErikHatcher:
https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters?action=diffrev1=146rev2=147

Comment:
added PatternCaptureGroupFilterFactory

  . Example: ` Kittens!   , Duck == Kittens!, Duck`.

 Optionally, the updateOffsets attribute will update the start and end
position offsets.
+
+ Anchor(PatternCaptureGroupFilter)
+
+ === solr.PatternCaptureGroupFilterFactory ===
+ ! [[Solr4.4]]
+
+ Emits tokens for each capture group in a regular expression
+
+ For example, the following definition will tokenize the input text of
http://www.foo.com/index; into http://www.foo.com; and www.foo.com.
+
+ {{{
+fieldType name=url_base class=solr.TextField
positionIncrementGap=100
+  analyzer
+tokenizer class=solr.KeywordTokenizerFactory
+filter class=solr.PatternCaptureGroupTokenFilter
pattern=(https?://([a-zA-Z\-_0-9.]+)) preserve_original=false
+  /analyzer
+/fieldType
+ }}}
+
+ If none of the patterns match, or if preserve_original is true, the
original token will also be emitted.
+

 === solr.PatternReplaceFilterFactory ===
 Like the !PatternReplaceCharFilterFactory, but operates post-tokenization.
See When to use a Char Filter vs. a Token Filter above.


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



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

Re: Where to aim a patch

2013-06-26 Thread Chris Hostetter


: One thing to think about is if you develop on trunk and forget to merge to
: 4.x, thats ok. the other way around is bad though, it basically creates an
: instant regression.
: 
: So I'm a little worried about this. I think development should be against
: trunk!

+1 ... for me it's never been a question of the tools -- i've never 
trusted the merge props to help keep anything straight.  I'm first and 
foremost concerned about features/fixes making it into 4x that then vanish 
when 5x comes out.

Knowing that logical commits are only flow in one direction (even if the 
physical bits being changed are different) is really helpful for keeping 
sane ... particulaly when you start seeing test failures in 4x but not 
trunk, or vice versa:  The number of possible causes doubles when there's 
a chance someone made a logical commit to 4x that never made it to trunk 
(was a bug committed to X but not Y? was a fix committed to Y but not X?)


-Hoss

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

[jira] [Commented] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.


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

Uwe Schindler commented on LUCENE-5079:
---

bq. edit: Actually, it depends on the exact semantics we're looking for. I 
guess I'll go with synchronized(this) for now for the greater safety.

That is the only correct way to do it! {{lastCommitChangeCount}} is always 
guarded by synchronized(this) in the whole code. Any synchronization in this 
method is unlikely to be a bottleneck, as you wonÄt call this method all the 
time :-)

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.


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

Uwe Schindler commented on LUCENE-5079:
---

Alternatively you can make the whole method synchronized. sync(this) is just 
more explicit and goes in line with the other uses of lastCommitChangeCount

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.

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

Yonik Seeley edited comment on SOLR-4926 at 6/26/13 5:33 PM:
-

bq. I have this competing approach attached

Yeah, I like the rollback right before... safer in the event that somehow the
IW acquires more changes. I was initially worried about code that uses the IW
to reopen the reader, but that code (openSearcher) doesn't force open a writer
and has a fallback to reopen on the reader.

I'll start looping the chaos test with your patch and see how it goes.
edit: 20 passes so far... commit it!

was (Author: ysee...@gmail.com):
bq. I have this competing approach attached

I'll start looping the chaos test with your patch and see how it goes.

I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
-

Key: SOLR-4926
URL: https://issues.apache.org/jira/browse/SOLR-4926
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
Fix For: 5.0, 4.4

Attachments: SOLR-4926.patch

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

[jira] [Updated] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.


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

Yonik Seeley updated LUCENE-5079:
-

Attachment: LUCENE-5079.patch

Actually, I'm leaning again toward a fast version since it might be nice to 
have on a GUI display and it's not clear how long IW may spend holding the lock 
on this.

After further code review, using a volatile seems safe.

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch, LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.


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

Yonik Seeley commented on LUCENE-5079:
--

bq. Any synchronization in this method is unlikely to be a bottleneck

It's unclear to me if there is any IO that goes on with the lock on this 
held...

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch, LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.

2013-06-26 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-5079:


I think volatile is best ... there is IO that happens when this is locked, 
e.g. when applying deletes.

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Attachments: LUCENE-5079.patch, LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4963) Schema Browser does not report stats properly on TrieDateField

2013-06-26 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-4963:


Thomas, 

Consider it from this perspective: if you had a TrieIntField with no 
precisionStep you would only see terms for the exist values indexed.  if you 
then set precisionStep=4, because you read the docs and saw that doing so would 
add additional synthetic terms to improve the speed of range queries, you would 
probably be equally confused if you came to this page and did _not_ see the new 
synthetic terms represented in the term statistics.

this is a low level page -- it doesn't hide anything from you about what's in 
the index.

From your perspective, what would help make the output less confusing?  
(keeping in mind the general nature of the Schema Browsing UI -- we can't 
really add anything too specific about any one time of field (Trie or 
otherwise)

Is there some general verbage we could add to the screen to help make it clear 
what you were looking at?





 Schema Browser does not report stats properly on TrieDateField
 --

 Key: SOLR-4963
 URL: https://issues.apache.org/jira/browse/SOLR-4963
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.3
 Environment: Customized single-core Solr from example running in 
 default Jetty server.
 Apple Inc. Java HotSpot(TM) 64-Bit Server VM (1.6.0_51 20.51-b01-456)
Reporter: Thomas Murphy
Priority: Minor
 Attachments: luke-date.json, solr-admin-query-facet-date.png, 
 solr-admin-schema-browser-date.png


 Loading documents into a schema with a TrieDateField and viewing that field 
 in the Schema Browser has distinctly wrong information displayed. Encountered 
 using psudo-randomly generated data. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4965) avoid commit creating new segments file if no changes

Yonik Seeley created SOLR-4965:
--

 Summary: avoid commit creating new segments file if no changes
 Key: SOLR-4965
 URL: https://issues.apache.org/jira/browse/SOLR-4965
 Project: Solr
  Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor


We could use LUCENE-5079 to avoid calling commit if there are no changes (and 
the act of setting commit user data causes changes, so IW.commit can't 
short-circuit for us as it used to do).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4945) Japanese Autocomplete and Highlighter broken

2013-06-26 Thread Shruthi Khatawkar (JIRA)

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

Shruthi Khatawkar commented on SOLR-4945:
-

Thanks Christian.

We are using Solr 1.4.1 version, is JapaneseTokenizerFactory compatible with
this version?

Regards,
Shruthi

Japanese Autocomplete and Highlighter broken

Key: SOLR-4945
URL: https://issues.apache.org/jira/browse/SOLR-4945
Project: Solr
Issue Type: Bug
Components: highlighter
Reporter: Shruthi Khatawkar

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

[jira] [Commented] (SOLR-4945) Japanese Autocomplete and Highlighter broken

2013-06-26 Thread Christian Moen (JIRA)

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

Christian Moen commented on SOLR-4945:
--

No, it's not. {{JapaneseTokenizerFactory}} is available in 3.6 or newer.
Kindly upgrade to the latest version of Solr (currently 4.3.1) and see if the
problem persists. If it does, please indicate how you reproduced it in detail
so we can start investigating the cause. Thanks.

Japanese Autocomplete and Highlighter broken

Key: SOLR-4945
URL: https://issues.apache.org/jira/browse/SOLR-4945
Project: Solr
Issue Type: Bug
Components: highlighter
Reporter: Shruthi Khatawkar

-
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.7.0_25) - Build # 6322 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6322/
Java: 32bit/jdk1.7.0_25 -client -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 30958 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:386: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:325: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:120: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* solr/webapp/web/css/styles/documents.css
* solr/webapp/web/js/lib/jquery.ajaxfileupload.js
* solr/webapp/web/js/scripts/documents.js
* solr/webapp/web/tpl/documents.html

Total time: 49 minutes 57 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.7.0_25 -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

[jira] [Commented] (SOLR-4945) Japanese Autocomplete and Highlighter broken

2013-06-26 Thread Shruthi Khatawkar (JIRA)

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

Shruthi Khatawkar commented on SOLR-4945:
-

Thanks Christian.

As of now we have no plans to upgrade Solr, is there any other way I can
resolve this?

Apparently, we have Autocomplete and Highlight working fine for most of our
other languages.

Regards,
Shruthi

Japanese Autocomplete and Highlighter broken

Key: SOLR-4945
URL: https://issues.apache.org/jira/browse/SOLR-4945
Project: Solr
Issue Type: Bug
Components: highlighter
Reporter: Shruthi Khatawkar

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

[jira] [Resolved] (LUCENE-5079) allow IndexWriter user to tell if there are uncommitted changes.


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

Yonik Seeley resolved LUCENE-5079.
--

   Resolution: Fixed
Fix Version/s: 4.4
   5.0

 allow IndexWriter user to tell if there are uncommitted changes.
 

 Key: LUCENE-5079
 URL: https://issues.apache.org/jira/browse/LUCENE-5079
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Yonik Seeley
 Fix For: 5.0, 4.4

 Attachments: LUCENE-5079.patch, LUCENE-5079.patch


 IndexWriter already currently tracks if there are uncommitted changes.  We 
 should expose this somehow... perhaps a boolean hasUncommittedChanges()?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4943) Add a new info admin handler.

2013-06-26 Thread Hoss Man (JIRA)


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

Hoss Man updated SOLR-4943:
---

Attachment: SOLR-4943-3__hoss_variant.patch

bq. I much prefer this ...

I know, agree to disagree

bq. I think it's fairly simple atm

Complex probably wasn't the right word .. the code is simple, but it left the 
door open very side for someone to introduce bugs in the future for one code 
path or the other.

Take a look at this SOLR-4943-3__hoss_variant.patch i'm attaching -- to me this 
is just as simple and easy to understand as what you had, but makes it a lot 
harder for someone down the road to break it w/o getting an obvious compile 
failure because the static methods limit what the code has access to (and if 
they change the signature of hte static method, then they'll get a compile 
error in InfoHandler and realize why the code is written the way it is.

bq. if it's bothersome, I'd prefer we just remove them at the core level for 
5.0 rather than try and refactor it to be very slightly simpler code. 

+1 ... starting with my SOLR-4943-3__hoss_variant.patch it would be trivial to 
move those static methods into InfoHandler ... they could still be called from 
the existing handlers, but those handlers would be marked deprecated.


 Add a new info admin handler.
 -

 Key: SOLR-4943
 URL: https://issues.apache.org/jira/browse/SOLR-4943
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 5.0, 4.4

 Attachments: SOLR-4943-2.patch, SOLR-4943-3__hoss_variant.patch, 
 SOLR-4943-3.patch, SOLR-4943.patch


 Currently, you have to specify a core to get system information for a variety 
 of request handlers - properties, logging, thread dump, system, etc.
 These should be available at a system location and not core specific location.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_25) - Build # 6251 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6251/
Java: 32bit/jdk1.7.0_25 -client -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 31240 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:392: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:331: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:120: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* solr/webapp/web/css/styles/documents.css
* solr/webapp/web/js/lib/jquery.ajaxfileupload.js
* solr/webapp/web/js/scripts/documents.js
* solr/webapp/web/tpl/documents.html

Total time: 45 minutes 36 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.7.0_25 -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] [Commented] (SOLR-4916) Add support to write and read Solr index files and transaction log files to and from HDFS.


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

Mark Miller commented on SOLR-4916:
---

Okay, now that SOLR-4926 is squared away, I am ready to commit this.

I'm sure that it's going to make the shadow maven build angry.

 Add support to write and read Solr index files and transaction log files to 
 and from HDFS.
 --

 Key: SOLR-4916
 URL: https://issues.apache.org/jira/browse/SOLR-4916
 Project: Solr
  Issue Type: New Feature
Reporter: Mark Miller
Assignee: Mark Miller
 Attachments: SOLR-4916.patch, SOLR-4916.patch, SOLR-4916.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.


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

Mark Miller resolved SOLR-4926.
---

Resolution: Fixed

Thanks Yonik!

 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4

 Attachments: SOLR-4926.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4916) Add support to write and read Solr index files and transaction log files to and from HDFS.


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

Steve Rowe commented on SOLR-4916:
--

Who knows what evil lurks in the heart of Solr?  The shadow maven build knows...

 Add support to write and read Solr index files and transaction log files to 
 and from HDFS.
 --

 Key: SOLR-4916
 URL: https://issues.apache.org/jira/browse/SOLR-4916
 Project: Solr
  Issue Type: New Feature
Reporter: Mark Miller
Assignee: Mark Miller
 Attachments: SOLR-4916.patch, SOLR-4916.patch, SOLR-4916.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.


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

Mark Miller commented on SOLR-4926:
---

The commit bot got knocked out because JIRA started responding that it was not 
authorized.

committed:
5x 1497020
4x 1497022

 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4

 Attachments: SOLR-4926.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[VOTE] Release PyLucene 4.3.1-1

2013-06-26 Thread Andi Vajda



The PyLucene 4.3.1-1 release tracking the recent release of Apache Lucene 
4.3.1 is ready.


A release candidate is available from:
http://people.apache.org/~vajda/staging_area/

A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_3/CHANGES

PyLucene 4.3.1 is built with JCC 2.16 included in these release artifacts:
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES

A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_3_1/lucene/CHANGES.txt

Please vote to release these artifacts as PyLucene 4.3.1-1.

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS

pps: here is my +1

[jira] [Commented] (SOLR-4926) I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.


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

Mark Miller commented on SOLR-4926:
---

Yonik follow up with

4x 1497055 get latest commit from deletion policy
5x 1497054 get latest commit from deletion policy

 I am seeing RecoveryZkTest and ChaosMonkeySafeLeaderTest fail often on trunk.
 -

 Key: SOLR-4926
 URL: https://issues.apache.org/jira/browse/SOLR-4926
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Blocker
 Fix For: 5.0, 4.4

 Attachments: SOLR-4926.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4966) CSS, JS and other files in webapp without license

Uwe Schindler created SOLR-4966:
---

 Summary: CSS, JS and other files in webapp without license
 Key: SOLR-4966
 URL: https://issues.apache.org/jira/browse/SOLR-4966
 Project: Solr
  Issue Type: Bug
  Components: web gui
Reporter: Uwe Schindler
Priority: Blocker


Almost all javascript and css in the Solr web app have no license. This 
violates ASF requirements, so it is a blocker, as we cannot do any other 
relaese without fixing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4966) CSS, JS and other files in webapp without license


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

Uwe Schindler updated SOLR-4966:


Attachment: SOLR-4966.patch

The attached patch shows the problem, the following files have no license 
header and are also missing in NOTICE.txt (most of the files are 3rd party, so 
they must be listed with license in the NOTICE.txt):

{noformat}
 [echo] Unapproved licenses:
 [echo]
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/WEB-INF/weblogic.xml
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/chosen.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/analysis.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/cloud.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/common.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/cores.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/dashboard.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/dataimport.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/documents.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/index.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/java-properties.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/logging.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/menu.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/plugins.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/query.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/replication.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/schema-browser.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/css/styles/threads.css
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/ZeroClipboard.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/chosen.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/d3.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/highlight.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/jquery-1.7.2.min.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/jquery.autogrow.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/jquery.blockUI.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/jquery.cookie.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/jquery.form.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/jquery.jstree.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/jquery.timeago.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/lib/order.js
 [echo]   C:/Users/Uwe 
Schindler/Projects/lucene/trunk-lusolr3/solr/webapp/web/js/require.js
{noformat}

 CSS, JS and other files in webapp without license
 -

 Key: SOLR-4966
 URL: https://issues.apache.org/jira/browse/SOLR-4966
 Project: Solr
  Issue Type: Bug
  Components: web gui
Reporter: Uwe Schindler
Priority: Blocker
 Attachments: SOLR-4966.patch


 Almost all javascript and css in the Solr web app have no license. This 
 violates ASF requirements, so it is a blocker, as we cannot do any other 
 relaese without fixing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4966) CSS, JS and other files in webapp without license


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

Uwe Schindler updated SOLR-4966:


Attachment: SOLR-4966.patch

Simpler file pattern for {{$rat.additional-includes}}.

 CSS, JS and other files in webapp without license
 -

 Key: SOLR-4966
 URL: https://issues.apache.org/jira/browse/SOLR-4966
 Project: Solr
  Issue Type: Bug
  Components: web gui
Reporter: Uwe Schindler
Priority: Blocker
 Attachments: SOLR-4966.patch, SOLR-4966.patch


 Almost all javascript and css in the Solr web app have no license. This 
 violates ASF requirements, so it is a blocker, as we cannot do any other 
 relaese without fixing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4967) Frequent test fails in org.apache.solr.cloud.SyncSliceTest

Mark Miller created SOLR-4967:
-

 Summary: Frequent test fails in org.apache.solr.cloud.SyncSliceTest
 Key: SOLR-4967
 URL: https://issues.apache.org/jira/browse/SOLR-4967
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 5.0, 4.4


It looks like this started with either the recent distrib commit fix or the fix 
to wait to reconnect to zk forever, not 30 seconds. If that turns out to be the 
case, this is probably exposing an existing issue rather than anything new.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4966) CSS, JS and other files in webapp without license


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

Uwe Schindler updated SOLR-4966:


Attachment: (was: SOLR-4966.patch)

 CSS, JS and other files in webapp without license
 -

 Key: SOLR-4966
 URL: https://issues.apache.org/jira/browse/SOLR-4966
 Project: Solr
  Issue Type: Bug
  Components: web gui
Reporter: Uwe Schindler
Priority: Blocker
 Attachments: SOLR-4966.patch


 Almost all javascript and css in the Solr web app have no license. This 
 violates ASF requirements, so it is a blocker, as we cannot do any other 
 relaese without fixing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4965) avoid commit creating new segments file if no changes


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

Yonik Seeley resolved SOLR-4965.


   Resolution: Fixed
Fix Version/s: 4.4
   5.0

committed.

 avoid commit creating new segments file if no changes
 -

 Key: SOLR-4965
 URL: https://issues.apache.org/jira/browse/SOLR-4965
 Project: Solr
  Issue Type: Improvement
Reporter: Yonik Seeley
Priority: Minor
 Fix For: 5.0, 4.4


 We could use LUCENE-5079 to avoid calling commit if there are no changes (and 
 the act of setting commit user data causes changes, so IW.commit can't 
 short-circuit for us as it used to do).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Assigned] (LUCENE-5061) Add license headers to prettify.js files


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

Uwe Schindler reassigned LUCENE-5061:
-

Assignee: Uwe Schindler

 Add license headers to prettify.js files
 

 Key: LUCENE-5061
 URL: https://issues.apache.org/jira/browse/LUCENE-5061
 Project: Lucene - Core
  Issue Type: Task
Reporter: Uwe Schindler
Assignee: Uwe Schindler

 Followup after LUCENE-5055: The prettify JS files have no license header 
 (should be ASF according to Google Code). The minimized Javascript files were 
 compressed with suppressing license headers (yui-compressor has an option to 
 remove it, and this was done here, which does not conform to Apaches source 
 code requirements).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4916) Add support to write and read Solr index files and transaction log files to and from HDFS.


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

Mark Miller commented on SOLR-4916:
---

The commit-tag-bot user cannot currently log in - JIRA wants him to solve a 
captcha to log in, but doesn't seem to accept any of my answers. Bleh.

Committed:
5x: 1497072

 Add support to write and read Solr index files and transaction log files to 
 and from HDFS.
 --

 Key: SOLR-4916
 URL: https://issues.apache.org/jira/browse/SOLR-4916
 Project: Solr
  Issue Type: New Feature
Reporter: Mark Miller
Assignee: Mark Miller
 Attachments: SOLR-4916.patch, SOLR-4916.patch, SOLR-4916.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-5061) Add license headers to prettify.js files


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

Uwe Schindler resolved LUCENE-5061.
---

   Resolution: Fixed
Fix Version/s: 4.4
   5.0

Committed to trunk and 4.x

 Add license headers to prettify.js files
 

 Key: LUCENE-5061
 URL: https://issues.apache.org/jira/browse/LUCENE-5061
 Project: Lucene - Core
  Issue Type: Task
Reporter: Uwe Schindler
Assignee: Uwe Schindler
 Fix For: 5.0, 4.4


 Followup after LUCENE-5055: The prettify JS files have no license header 
 (should be ASF according to Google Code). The minimized Javascript files were 
 compressed with suppressing license headers (yui-compressor has an option to 
 remove it, and this was done here, which does not conform to Apaches source 
 code requirements).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Indexing file with security problem

2013-06-26 Thread lukasw

Hello

I'll try to briefly describe my problem and task.
My name is Lukas and i am Java developer , my task is to create search
engine for different types of file (only text file types) pdf, word, odf,
xml but not html.
I have got little experience with lucene about year ago i wrote simple full
text search using lucene and hibernate search. That was simple project. But
now i have got very difficult task with searching.
We are using java 1.7 and glassfish 3 and i have to concentrate only server
side approach not client ui. Ther is my three major problem :

1) All files is stored on webdav server, but information about file name ,
id file typ etc are stored into database (postgresql) so when i creating
index i need to use both information. As a result of query i need only
return file id from database. Summary content of file is stored in server
but information about file is stored in database so we must retrieve both.

2) Secondary problem it that  each file has a level of secrecy. But major
problem is that this level is calculated dynamically. When calculating level
of security for file we considering several properties. The static
properties is files location, the folder in which the file is, but also 
dynamic  information  user profiles user roles and departments . So when
user Maggie is logged she can search only files test.pdf , test2.doc
etc but if user Stev is logged he have got different profiles such a
Maggie so he can only search some phase in file broken.pdf, mybook.odt.
test2.doc etc . . I think that when for example user search phase
lucene +solr we search in all indexed documents and after that filtered
result. But i think that solution is  is not very efficient. What if results
count 100 files , so what next we filtered step by step each files  ? But i
do not see any other solution. Maybe you can help me and lucene or solr have
got mechanism to help.

3) Last problem is that some files are encrypted. So that files must be
indexed only once before encryption ! But i think that if we indexed secure
files so we get security issue. Because all word from that file is
tokenized.
I have not got any idea haw to secure lucene documents and index datastore ?
its possible ...


Also i have got question that i need to use Solr for my serarch engine or
using only lucene and write own search engine ? So as you can see i have not
got problem with indexing , serching but with security files and files
secured levels.

Thanks for any hints and time you spend for me. 



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Indexing-file-with-security-problem-tp4073394.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-MacOSX (64bit/jdk1.7.0) - Build # 599 - Failure!

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

All tests passed

Build Log:
[...truncated 34268 lines...]
BUILD FAILED
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:386: 
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:325: 
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/extra-targets.xml:120:
 The following files are missing svn:eol-style (or binary svn:mime-type):
* solr/webapp/web/css/styles/documents.css
* solr/webapp/web/js/lib/jquery.ajaxfileupload.js
* solr/webapp/web/js/scripts/documents.js
* solr/webapp/web/tpl/documents.html

Total time: 139 minutes 45 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

[jira] [Updated] (SOLR-4892) Add field update processors to parse/convert String-typed fields to Date, Number, and Boolean


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

Steve Rowe updated SOLR-4892:
-

Attachment: SOLR-4892.patch

[~hossman_luc...@fucit.org], this version of the patch includes fixes for all 
your suggestions.

Details: 

{quote} 
1) AllValuesOrNoneFieldMutatingUpdateProcessor semantics

The if (destVal == srcVal) ... do nothing logic [...] give subclasses another 
singleton marker object [...] they can return from mutateValue() to say abort 
processing this list i have encountered an object i do not want. If 
mutateValue() returns the same object it was passed in, that should be 
considered a successful mutation.
{quote}

Done.

{quote}
2) ParsingFieldUpdateProcessor overriding processAdd

[...] we don't need this class at all, classes like 
ParseFooFieldUpdateProcessor could easily just handle the CharSequence check as 
part of their basic logic...
{quote}

Done - I chose this route and got rid of ParsingFieldUpdateProcessor.

{quote}
3) either way we go with #2, that means we don't need the access modifieier 
change on 'selector' in FieldMutatingUpdateProcessor.
{quote}

Fixed.

{quote}
double check the handling of field boosts in 
AllValuesOrNoneFieldMutatingUpdateProcessor ... pretty sure it isn't being 
preserved (see FieldValueMutatingUpdateProcessor for example)
{quote]

Fixed.

{quote}
5) The SortableFooField FieldType's should also be decorated with your new 
interfaces.
{quote}

Done.

{quote}
6) Can we refactor the locale init param parsing into a helper utility class or 
a common factory bsae class so it's not duplicated in both 
ParseNumericFieldUpdateProcessorFactory and 
ParseDateFieldUpdateProcessorFactory ?

8) would it be simpler for users to have a single locale init param that 
accepted things like ru and ru_RU and ru_RU_xxx using 
LocaleUtils.toLocale in commons-lang?
{quote}

I switched to using a single locale config item, using commons-lang 
LocaleUtils.toLocale().  This is so small I didn't try to consolidate, I just 
replicated in the two places.

{quote}
7) Why no ParseIntFieldUpdateProcessor and ParseFloatFieldUpdateProcessor ?
{quote}

Added.

{quote}
9) we should be able to make the ParseFooFieldUpdateProcessor inner classses 
into static inner classes just by passing hte locale into the constructor and 
right?
{quote}

I did this for the Date and Numeric processors, but the Boolean processor 
factory has a couple of configured collections and a boolean, so I didn't 
convert its processor to a static inner class.


 Add field update processors to parse/convert String-typed fields to Date, 
 Number, and Boolean
 -

 Key: SOLR-4892
 URL: https://issues.apache.org/jira/browse/SOLR-4892
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Steve Rowe
Assignee: Steve Rowe
Priority: Minor
 Fix For: 4.4

 Attachments: SOLR-4892.patch, SOLR-4892.patch


 Add {{FieldMutatingUpdateProcessorFactory}} subclasses 
 {{ParseFooUpdateProcessorFactory}}, where {{Foo}} includes {{Date}}, 
 {{Double}}, {{Long}}, and {{Boolean}}.
 These factories will have a default selector that matches all fields that 
 either don’t match any schema field, or are in the schema with the 
 corresponding {{typeClass}}.  They can optionally support a list of multiple 
 format specifiers.  If they see a value that is not a CharSequence, or can't 
 parse the value using a configured format, they ignore it and leave it as is.
 For multi-valued fields, these processors will not convert any values unless 
 all are first successfully parsed.  Ordering the processors [Boolean, Long, 
 Double, Date] will allow e.g. values [2, 5, 8.6] to be left alone by the 
 Boolean and Long processors, but then converted by the Double processor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4916) Add support to write and read Solr index files and transaction log files to and from HDFS.


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

Uwe Schindler commented on SOLR-4916:
-

Mark: You missed to add the new dependencies to NOTICE.txt. This is especially 
important for CDDL files. *They have to be listed in NOTICE.txt*

Is there no solution for the jetty 1.6.26 classes? Can we add easymocks to work 
around the outdated jetty version, if its not actually used just referred to? 
The existence of jetty 1.6.26 is horrible, I would have -1 that if I would have 
seen earlier.

 Add support to write and read Solr index files and transaction log files to 
 and from HDFS.
 --

 Key: SOLR-4916
 URL: https://issues.apache.org/jira/browse/SOLR-4916
 Project: Solr
  Issue Type: New Feature
Reporter: Mark Miller
Assignee: Mark Miller
 Attachments: SOLR-4916.patch, SOLR-4916.patch, SOLR-4916.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-4892) Add field update processors to parse/convert String-typed fields to Date, Number, and Boolean


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

Steve Rowe edited comment on SOLR-4892 at 6/26/13 9:45 PM:
---

[~hossman_luc...@fucit.org], this version of the patch includes fixes for all 
your suggestions.

Details: 

{quote} 
1) AllValuesOrNoneFieldMutatingUpdateProcessor semantics

The if (destVal == srcVal) ... do nothing logic [...] give subclasses another 
singleton marker object [...] they can return from mutateValue() to say abort 
processing this list i have encountered an object i do not want. If 
mutateValue() returns the same object it was passed in, that should be 
considered a successful mutation.
{quote}

Done.

{quote}
2) ParsingFieldUpdateProcessor overriding processAdd

[...] we don't need this class at all, classes like 
ParseFooFieldUpdateProcessor could easily just handle the CharSequence check as 
part of their basic logic...
{quote}

Done - I chose this route and got rid of ParsingFieldUpdateProcessor.

{quote}
3) either way we go with #2, that means we don't need the access modifieier 
change on 'selector' in FieldMutatingUpdateProcessor.
{quote}

Fixed.

{quote}
double check the handling of field boosts in 
AllValuesOrNoneFieldMutatingUpdateProcessor ... pretty sure it isn't being 
preserved (see FieldValueMutatingUpdateProcessor for example)
{quote}

Fixed.

{quote}
5) The SortableFooField FieldType's should also be decorated with your new 
interfaces.
{quote}

Done.

{quote}
6) Can we refactor the locale init param parsing into a helper utility class or 
a common factory bsae class so it's not duplicated in both 
ParseNumericFieldUpdateProcessorFactory and 
ParseDateFieldUpdateProcessorFactory ?

8) would it be simpler for users to have a single locale init param that 
accepted things like ru and ru_RU and ru_RU_xxx using 
LocaleUtils.toLocale in commons-lang?
{quote}

I switched to using a single locale config item, using commons-lang 
LocaleUtils.toLocale().  This is so small I didn't try to consolidate, I just 
replicated in the two places.

{quote}
7) Why no ParseIntFieldUpdateProcessor and ParseFloatFieldUpdateProcessor ?
{quote}

Added.

{quote}
9) we should be able to make the ParseFooFieldUpdateProcessor inner classses 
into static inner classes just by passing hte locale into the constructor and 
right?
{quote}

I did this for the Date and Numeric processors, but the Boolean processor 
factory has a couple of configured collections and a boolean, so I didn't 
convert its processor to a static inner class.


  was (Author: steve_rowe):
[~hossman_luc...@fucit.org], this version of the patch includes fixes for 
all your suggestions.

Details: 

{quote} 
1) AllValuesOrNoneFieldMutatingUpdateProcessor semantics

The if (destVal == srcVal) ... do nothing logic [...] give subclasses another 
singleton marker object [...] they can return from mutateValue() to say abort 
processing this list i have encountered an object i do not want. If 
mutateValue() returns the same object it was passed in, that should be 
considered a successful mutation.
{quote}

Done.

{quote}
2) ParsingFieldUpdateProcessor overriding processAdd

[...] we don't need this class at all, classes like 
ParseFooFieldUpdateProcessor could easily just handle the CharSequence check as 
part of their basic logic...
{quote}

Done - I chose this route and got rid of ParsingFieldUpdateProcessor.

{quote}
3) either way we go with #2, that means we don't need the access modifieier 
change on 'selector' in FieldMutatingUpdateProcessor.
{quote}

Fixed.

{quote}
double check the handling of field boosts in 
AllValuesOrNoneFieldMutatingUpdateProcessor ... pretty sure it isn't being 
preserved (see FieldValueMutatingUpdateProcessor for example)
{quote]

Fixed.

{quote}
5) The SortableFooField FieldType's should also be decorated with your new 
interfaces.
{quote}

Done.

{quote}
6) Can we refactor the locale init param parsing into a helper utility class or 
a common factory bsae class so it's not duplicated in both 
ParseNumericFieldUpdateProcessorFactory and 
ParseDateFieldUpdateProcessorFactory ?

8) would it be simpler for users to have a single locale init param that 
accepted things like ru and ru_RU and ru_RU_xxx using 
LocaleUtils.toLocale in commons-lang?
{quote}

I switched to using a single locale config item, using commons-lang 
LocaleUtils.toLocale().  This is so small I didn't try to consolidate, I just 
replicated in the two places.

{quote}
7) Why no ParseIntFieldUpdateProcessor and ParseFloatFieldUpdateProcessor ?
{quote}

Added.

{quote}
9) we should be able to make the ParseFooFieldUpdateProcessor inner classses 
into static inner classes just by passing hte locale into the constructor and 
right?
{quote}

I did this for the Date and Numeric processors, but the Boolean processor 
factory has a couple of

Re: Where to aim a patch

2013-06-26 Thread Benson Margulies

Folks,

I asked this question to direct my work on SOLR-4872. I am happy to make
patches for that work on as many branches as needed -- what I lack is a
community decision on the design decision raised on that JIRA.

[jira] [Commented] (SOLR-4379) solr-core has a dependency to slf4j-jdk14 and is not binding agnostic


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

Shikhar Bhushan commented on SOLR-4379:
---

This is quite problematic, if you are transitively pulling in {{solr-core}}'s 
dependencies you'd get {{slf4j-jdk14}} on the classpath, and slf4j complains 
(not to speak of the potential for it selecting the wrong binding):

{noformat}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:redacted/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:redacted/lib/slf4j-jdk14-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
{noformat}

The fix should I think be as simple as adding {{scoperuntime/scope}} for 
{{slf4j-jdk14}} in the solr-core POM.

 solr-core has a dependency to slf4j-jdk14 and is not binding agnostic
 -

 Key: SOLR-4379
 URL: https://issues.apache.org/jira/browse/SOLR-4379
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.1
Reporter: Nicolas Labrot
Priority: Minor

 solr-core can be used as a dependency in other projects which used others 
 binding. In these cases slf4j-jdk14 must be excluded
 In my opinion it may be better to move the slf4j-jdk14 dependency from 
 solr-core to the war project. 
 solr-core will be binding agnostics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-4379) solr-core has a dependency to slf4j-jdk14 and is not binding agnostic


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

Shikhar Bhushan edited comment on SOLR-4379 at 6/26/13 9:52 PM:


This is quite problematic, if you are transitively pulling in {{solr-core}}'s 
dependencies you'd get {{slf4j-jdk14}} on the classpath, and slf4j complains 
(not to speak of the potential for it selecting the wrong binding):

{noformat}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:redacted/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:redacted/lib/slf4j-jdk14-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
{noformat}

The fix should I think be as simple as adding {{scopeprovided/scope}} for 
{{slf4j-jdk14}} in the solr-core POM.

  was (Author: shikhar):
This is quite problematic, if you are transitively pulling in 
{{solr-core}}'s dependencies you'd get {{slf4j-jdk14}} on the classpath, and 
slf4j complains (not to speak of the potential for it selecting the wrong 
binding):

{noformat}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:redacted/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:redacted/lib/slf4j-jdk14-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
{noformat}

The fix should I think be as simple as adding {{scoperuntime/scope}} for 
{{slf4j-jdk14}} in the solr-core POM.
  
 solr-core has a dependency to slf4j-jdk14 and is not binding agnostic
 -

 Key: SOLR-4379
 URL: https://issues.apache.org/jira/browse/SOLR-4379
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.1
Reporter: Nicolas Labrot
Priority: Minor

 solr-core can be used as a dependency in other projects which used others 
 binding. In these cases slf4j-jdk14 must be excluded
 In my opinion it may be better to move the slf4j-jdk14 dependency from 
 solr-core to the war project. 
 solr-core will be binding agnostics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4916) Add support to write and read Solr index files and transaction log files to and from HDFS.


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

Mark Miller commented on SOLR-4916:
---

bq. You missed to add the new dependencies to NOTICE.txt.

Yeah, I only added blur - I'll look at what else should be added.

bq. Is there no solution for the jetty 1.6.26 classes?

I'm not really concerned about it atm - it's a dependency that the tests have 
for running the namenode - it's only a test framework dependency and all of the 
package names are different than in later version of jetty so they don't 
overlap.

 Add support to write and read Solr index files and transaction log files to 
 and from HDFS.
 --

 Key: SOLR-4916
 URL: https://issues.apache.org/jira/browse/SOLR-4916
 Project: Solr
  Issue Type: New Feature
Reporter: Mark Miller
Assignee: Mark Miller
 Attachments: SOLR-4916.patch, SOLR-4916.patch, SOLR-4916.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins


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

Yonik Seeley commented on SOLR-3076:


OK, now that compound-file test related failures have been nailed, I'm back to 
looking at this.

bq. Just keep in mind several improvements:

Thanks, I'll check those suggestions out.
As for the stuff that there is no support for, the list seems to be getting big 
as I look at it... I think I'll try for a more minimalistic approach and leave 
the other stuff for follow-on work if possible.


 Solr(Cloud) should support block joins
 --

 Key: SOLR-3076
 URL: https://issues.apache.org/jira/browse/SOLR-3076
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Yonik Seeley
 Fix For: 5.0, 4.4

 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, 
 bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, 
 child-bjqparser.patch, dih-3076.patch, dih-config.xml, 
 parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 
 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, 
 SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, 
 SOLR-3076.patch, SOLR-3076.patch, 
 SOLR-7036-childDocs-solr-fork-trunk-patched, 
 solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, 
 tochild-bjq-filtered-search-fix.patch


 Lucene has the ability to do block joins, we should add it to Solr.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-4379) solr-core has a dependency to slf4j-jdk14 and is not binding agnostic


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

Shikhar Bhushan edited comment on SOLR-4379 at 6/26/13 9:55 PM:


This is quite problematic, if you are transitively pulling in {{solr-core}}'s 
dependencies you'd get {{slf4j-jdk14}} on the classpath, and slf4j complains 
(not to speak of the potential for it selecting the wrong binding):

{noformat}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:redacted/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:redacted/lib/slf4j-jdk14-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
{noformat}

The fix should I think be as simple as adding {{scoperuntime/scope}} (or 
{{scopeprovided/scope}}? -- not sure) for {{slf4j-jdk14}} in the solr-core 
POM.

  was (Author: shikhar):
This is quite problematic, if you are transitively pulling in 
{{solr-core}}'s dependencies you'd get {{slf4j-jdk14}} on the classpath, and 
slf4j complains (not to speak of the potential for it selecting the wrong 
binding):

{noformat}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:redacted/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:redacted/lib/slf4j-jdk14-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
{noformat}

The fix should I think be as simple as adding {{scopeprovided/scope}} for 
{{slf4j-jdk14}} in the solr-core POM.
  
 solr-core has a dependency to slf4j-jdk14 and is not binding agnostic
 -

 Key: SOLR-4379
 URL: https://issues.apache.org/jira/browse/SOLR-4379
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.1
Reporter: Nicolas Labrot
Priority: Minor

 solr-core can be used as a dependency in other projects which used others 
 binding. In these cases slf4j-jdk14 must be excluded
 In my opinion it may be better to move the slf4j-jdk14 dependency from 
 solr-core to the war project. 
 solr-core will be binding agnostics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4379) solr-core has a dependency to slf4j-jdk14 and is not binding agnostic


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

Shikhar Bhushan commented on SOLR-4379:
---

looks like this is fixed in 4.3.1 at least: 
http://repo1.maven.org/maven2/org/apache/solr/solr-core/4.3.1/solr-core-4.3.1.pom
 has no mention of {{slf4j-jdk14}}

 solr-core has a dependency to slf4j-jdk14 and is not binding agnostic
 -

 Key: SOLR-4379
 URL: https://issues.apache.org/jira/browse/SOLR-4379
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.1
Reporter: Nicolas Labrot
Priority: Minor

 solr-core can be used as a dependency in other projects which used others 
 binding. In these cases slf4j-jdk14 must be excluded
 In my opinion it may be better to move the slf4j-jdk14 dependency from 
 solr-core to the war project. 
 solr-core will be binding agnostics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4379) solr-core has a dependency to slf4j-jdk14 and is not binding agnostic


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

Shikhar Bhushan commented on SOLR-4379:
---

context http://wiki.apache.org/solr/SolrLogging#Solr_4.3_and_above

 solr-core has a dependency to slf4j-jdk14 and is not binding agnostic
 -

 Key: SOLR-4379
 URL: https://issues.apache.org/jira/browse/SOLR-4379
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.1
Reporter: Nicolas Labrot
Priority: Minor

 solr-core can be used as a dependency in other projects which used others 
 binding. In these cases slf4j-jdk14 must be excluded
 In my opinion it may be better to move the slf4j-jdk14 dependency from 
 solr-core to the war project. 
 solr-core will be binding agnostics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4916) Add support to write and read Solr index files and transaction log files to and from HDFS.


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

Mark Miller commented on SOLR-4916:
---

5x: r1497133 Update NOTICE file and remove log4j from test-framework 
dependencies

 Add support to write and read Solr index files and transaction log files to 
 and from HDFS.
 --

 Key: SOLR-4916
 URL: https://issues.apache.org/jira/browse/SOLR-4916
 Project: Solr
  Issue Type: New Feature
Reporter: Mark Miller
Assignee: Mark Miller
 Attachments: SOLR-4916.patch, SOLR-4916.patch, SOLR-4916.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: svn commit: r1497131 - in /lucene/dev/trunk/solr/licenses: javassist-3.6.0.GA-LICENSE-MPL.txt javassist-3.6.0.GA-NOTICE.txt

2013-06-26 Thread Robert Muir

Thanks Uwe for fixing.

I want to open an issue for this to see if we can fix the checker.

If a license file matches no jars, we should fail: extra bogus licenses
If  1 license file matches a jar, we should fail too!

On Wed, Jun 26, 2013 at 6:06 PM, uschind...@apache.org wrote:

 Author: uschindler
 Date: Wed Jun 26 22:06:08 2013
 New Revision: 1497131

 URL: http://svn.apache.org/r1497131
 Log:
 Remove license files no longer in use

 Removed:
 lucene/dev/trunk/solr/licenses/javassist-3.6.0.GA-LICENSE-MPL.txt
 lucene/dev/trunk/solr/licenses/javassist-3.6.0.GA-NOTICE.txt

[jira] [Commented] (SOLR-4916) Add support to write and read Solr index files and transaction log files to and from HDFS.


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

Uwe Schindler commented on SOLR-4916:
-

Thanks!

 Add support to write and read Solr index files and transaction log files to 
 and from HDFS.
 --

 Key: SOLR-4916
 URL: https://issues.apache.org/jira/browse/SOLR-4916
 Project: Solr
  Issue Type: New Feature
Reporter: Mark Miller
Assignee: Mark Miller
 Attachments: SOLR-4916.patch, SOLR-4916.patch, SOLR-4916.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4892) Add field update processors to parse/convert String-typed fields to Date, Number, and Boolean

2013-06-26 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-4892:


+1 ... code looks good.

two minor things i didn't notice before...

a) i think there's some class javadoc cut/paste mistakes ... if you grep the 
patch for solr.ParseDoubleFieldUpdateProcessorFactory it shows up in the 
class jdocs for several other factories.

b) the logic in ParseBooleanFieldUpdateProcessorFactory could probably be a 
little simpler/faster if there was a single {{MapString,Boolean}} instead of 
two {{SetString}} that each had to be checked.

 Add field update processors to parse/convert String-typed fields to Date, 
 Number, and Boolean
 -

 Key: SOLR-4892
 URL: https://issues.apache.org/jira/browse/SOLR-4892
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Steve Rowe
Assignee: Steve Rowe
Priority: Minor
 Fix For: 4.4

 Attachments: SOLR-4892.patch, SOLR-4892.patch


 Add {{FieldMutatingUpdateProcessorFactory}} subclasses 
 {{ParseFooUpdateProcessorFactory}}, where {{Foo}} includes {{Date}}, 
 {{Double}}, {{Long}}, and {{Boolean}}.
 These factories will have a default selector that matches all fields that 
 either don’t match any schema field, or are in the schema with the 
 corresponding {{typeClass}}.  They can optionally support a list of multiple 
 format specifiers.  If they see a value that is not a CharSequence, or can't 
 parse the value using a configured format, they ignore it and leave it as is.
 For multi-valued fields, these processors will not convert any values unless 
 all are first successfully parsed.  Ordering the processors [Boolean, Long, 
 Double, Date] will allow e.g. values [2, 5, 8.6] to be left alone by the 
 Boolean and Long processors, but then converted by the Double processor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

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

2013-06-26 Thread Apache Jenkins Server

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

All tests passed

Build Log:
[...truncated 20533 lines...]
  [mvn] [INFO] -
  [mvn] [INFO] -
  [mvn] [ERROR] COMPILATION ERROR : 
  [mvn] [INFO] -

[...truncated 642 lines...]



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

[jira] [Created] (SOLR-4968) The collection alias api should have a list cmd.

Mark Miller created SOLR-4968:
-

 Summary: The collection alias api should have a list cmd.
 Key: SOLR-4968
 URL: https://issues.apache.org/jira/browse/SOLR-4968
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 5.0, 4.4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4916) Add support to write and read Solr index files and transaction log files to and from HDFS.


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

Mark Miller commented on SOLR-4916:
---

5x: r1497159 add assume false to test for java 8

 Add support to write and read Solr index files and transaction log files to 
 and from HDFS.
 --

 Key: SOLR-4916
 URL: https://issues.apache.org/jira/browse/SOLR-4916
 Project: Solr
  Issue Type: New Feature
Reporter: Mark Miller
Assignee: Mark Miller
 Attachments: SOLR-4916.patch, SOLR-4916.patch, SOLR-4916.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_25) - Build # 6326 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6326/
Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 31022 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:386: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:325: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:120: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* dev-tools/idea/.idea/libraries/Solr_test_framework_library.xml

Total time: 44 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.7.0_25 -server -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-4892) Add field update processors to parse/convert String-typed fields to Date, Number, and Boolean


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

Steve Rowe updated SOLR-4892:
-

Attachment: SOLR-4892.patch

Final patch.

Beefed up tests and addressed Hoss's javadocs and map vs. two sets issues.

Committing shortly.

 Add field update processors to parse/convert String-typed fields to Date, 
 Number, and Boolean
 -

 Key: SOLR-4892
 URL: https://issues.apache.org/jira/browse/SOLR-4892
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Steve Rowe
Assignee: Steve Rowe
Priority: Minor
 Fix For: 4.4

 Attachments: SOLR-4892.patch, SOLR-4892.patch, SOLR-4892.patch


 Add {{FieldMutatingUpdateProcessorFactory}} subclasses 
 {{ParseFooUpdateProcessorFactory}}, where {{Foo}} includes {{Date}}, 
 {{Double}}, {{Long}}, and {{Boolean}}.
 These factories will have a default selector that matches all fields that 
 either don’t match any schema field, or are in the schema with the 
 corresponding {{typeClass}}.  They can optionally support a list of multiple 
 format specifiers.  If they see a value that is not a CharSequence, or can't 
 parse the value using a configured format, they ignore it and leave it as is.
 For multi-valued fields, these processors will not convert any values unless 
 all are first successfully parsed.  Ordering the processors [Boolean, Long, 
 Double, Date] will allow e.g. values [2, 5, 8.6] to be left alone by the 
 Boolean and Long processors, but then converted by the Double processor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4892) Add field update processors to parse/convert String-typed fields to Date, Number, and Boolean


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

Steve Rowe resolved SOLR-4892.
--

   Resolution: Fixed
Fix Version/s: 5.0

Committed:

- trunk [r1497165|http://svn.apache.org/r1497165]
- branch_4x [r1497177|http://svn.apache.org/r1497177]

Thanks for the reviews Hoss!

 Add field update processors to parse/convert String-typed fields to Date, 
 Number, and Boolean
 -

 Key: SOLR-4892
 URL: https://issues.apache.org/jira/browse/SOLR-4892
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Steve Rowe
Assignee: Steve Rowe
Priority: Minor
 Fix For: 5.0, 4.4

 Attachments: SOLR-4892.patch, SOLR-4892.patch, SOLR-4892.patch


 Add {{FieldMutatingUpdateProcessorFactory}} subclasses 
 {{ParseFooUpdateProcessorFactory}}, where {{Foo}} includes {{Date}}, 
 {{Double}}, {{Long}}, and {{Boolean}}.
 These factories will have a default selector that matches all fields that 
 either don’t match any schema field, or are in the schema with the 
 corresponding {{typeClass}}.  They can optionally support a list of multiple 
 format specifiers.  If they see a value that is not a CharSequence, or can't 
 parse the value using a configured format, they ignore it and leave it as is.
 For multi-valued fields, these processors will not convert any values unless 
 all are first successfully parsed.  Ordering the processors [Boolean, Long, 
 Double, Date] will allow e.g. values [2, 5, 8.6] to be left alone by the 
 Boolean and Long processors, but then converted by the Double processor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

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

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6327/
Java: 64bit/jdk1.7.0_25 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 3 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:386: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:325: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:120: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* dev-tools/idea/.idea/libraries/Solr_test_framework_library.xml

Total time: 47 minutes 56 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.7.0_25 -XX:-UseCompressedOops -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

Re: Indexing file with security problem

2013-06-26 Thread Otis Gospodnetic

Hi,

I would start from ManifoldCF - it may save you some work.

Otis
Solr  ElasticSearch Support
http://sematext.com/
On Jun 26, 2013 5:01 PM, lukasw lukas...@gmail.com wrote:

 Hello

 I'll try to briefly describe my problem and task.
 My name is Lukas and i am Java developer , my task is to create search
 engine for different types of file (only text file types) pdf, word, odf,
 xml but not html.
 I have got little experience with lucene about year ago i wrote simple full
 text search using lucene and hibernate search. That was simple project. But
 now i have got very difficult task with searching.
 We are using java 1.7 and glassfish 3 and i have to concentrate only server
 side approach not client ui. Ther is my three major problem :

 1) All files is stored on webdav server, but information about file name ,
 id file typ etc are stored into database (postgresql) so when i creating
 index i need to use both information. As a result of query i need only
 return file id from database. Summary content of file is stored in server
 but information about file is stored in database so we must retrieve both.

 2) Secondary problem it that  each file has a level of secrecy. But major
 problem is that this level is calculated dynamically. When calculating
 level
 of security for file we considering several properties. The static
 properties is files location, the folder in which the file is, but also
 dynamic  information  user profiles user roles and departments . So when
 user Maggie is logged she can search only files test.pdf , test2.doc
 etc but if user Stev is logged he have got different profiles such a
 Maggie so he can only search some phase in file broken.pdf, mybook.odt.
 test2.doc etc . . I think that when for example user search phase
 lucene +solr we search in all indexed documents and after that filtered
 result. But i think that solution is  is not very efficient. What if
 results
 count 100 files , so what next we filtered step by step each files  ? But i
 do not see any other solution. Maybe you can help me and lucene or solr
 have
 got mechanism to help.

 3) Last problem is that some files are encrypted. So that files must be
 indexed only once before encryption ! But i think that if we indexed secure
 files so we get security issue. Because all word from that file is
 tokenized.
 I have not got any idea haw to secure lucene documents and index datastore
 ?
 its possible ...


 Also i have got question that i need to use Solr for my serarch engine or
 using only lucene and write own search engine ? So as you can see i have
 not
 got problem with indexing , serching but with security files and files
 secured levels.

 Thanks for any hints and time you spend for me.



 --
 View this message in context:
 http://lucene.472066.n3.nabble.com/Indexing-file-with-security-problem-tp4073394.html
 Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[jira] [Created] (SOLR-4969) Enable ChaosMonkeyNothingIsSafeTest

Mark Miller created SOLR-4969:
-

 Summary: Enable ChaosMonkeyNothingIsSafeTest
 Key: SOLR-4969
 URL: https://issues.apache.org/jira/browse/SOLR-4969
 Project: Solr
  Issue Type: Task
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 5.0, 4.4


This test is currently marked as a @badapple - I run it on my local jenkins 
though, and it's behaved much better since some changes that were made today. 
I'd like to play around with removing @badapple from this test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

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