date:20130424


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

Simon Willnauer updated LUCENE-4766:


Attachment: LUCENE-4766.patch

here is a new patch, updated to trunk and moved over to use capturerestore 
state. I think this one is ready, I will commit this today if nobody objects.

 Pattern token filter which emits a token for every capturing group
 --

 Key: LUCENE-4766
 URL: https://issues.apache.org/jira/browse/LUCENE-4766
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.1
Reporter: Clinton Gormley
Assignee: Simon Willnauer
Priority: Minor
  Labels: analysis, feature, lucene
 Fix For: 4.3

 Attachments: LUCENE-4766.patch, LUCENE-4766.patch, LUCENE-4766.patch, 
 LUCENE-4766.patch, LUCENE-4766.patch


 The PatternTokenizer either functions by splitting on matches, or allows you 
 to specify a single capture group.  This is insufficient for my needs. Quite 
 often I want to capture multiple overlapping tokens in the same position.
 I've written a pattern token filter which accepts multiple patterns and emits 
 tokens for every capturing group that is matched in any pattern.
 Patterns are not anchored to the beginning and end of the string, so each 
 pattern can produce multiple matches.
 For instance a pattern like :
 {code}
 (([a-z]+)(\d*))
 {code}
 when matched against: 
 {code}
 abc123def456
 {code}
 would produce the tokens:
 {code}
 abc123, abc, 123, def456, def, 456
 {code}
 Multiple patterns can be applied, eg these patterns could be used for 
 camelCase analysis:
 {code}
 ([A-Z]{2,}),
 (?![A-Z])([A-Z][a-z]+),
 (?:^|\\b|(?=[0-9_])|(?=[A-Z]{2}))([a-z]+),
 ([0-9]+)
 {code}
 When matched against the string letsPartyLIKEits1999_dude, they would 
 produce the tokens:
 {code}
 lets, Party, LIKE, its, 1999, dude
 {code}
 If no token is emitted, the original token is preserved. 
 If the preserveOriginal flag is true, it will output the full original token 
 (ie letsPartyLIKEits1999_dude) in addition to any matching tokens (but in 
 this case, if a matching token is identical to the original, it will only 
 emit one copy of the full token).
 Multiple patterns are required to allow overlapping captures, but also means 
 that patterns are less dense and easier to understand.
 This is my first Java code, so apologies if I'm doing something stupid.

--
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-4766) Pattern token filter which emits a token for every capturing group


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

Simon Willnauer updated LUCENE-4766:


Attachment: (was: LUCENE-4766.patch)

 Pattern token filter which emits a token for every capturing group
 --

 Key: LUCENE-4766
 URL: https://issues.apache.org/jira/browse/LUCENE-4766
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.1
Reporter: Clinton Gormley
Assignee: Simon Willnauer
Priority: Minor
  Labels: analysis, feature, lucene
 Fix For: 4.3

 Attachments: LUCENE-4766.patch, LUCENE-4766.patch, LUCENE-4766.patch, 
 LUCENE-4766.patch, LUCENE-4766.patch


 The PatternTokenizer either functions by splitting on matches, or allows you 
 to specify a single capture group.  This is insufficient for my needs. Quite 
 often I want to capture multiple overlapping tokens in the same position.
 I've written a pattern token filter which accepts multiple patterns and emits 
 tokens for every capturing group that is matched in any pattern.
 Patterns are not anchored to the beginning and end of the string, so each 
 pattern can produce multiple matches.
 For instance a pattern like :
 {code}
 (([a-z]+)(\d*))
 {code}
 when matched against: 
 {code}
 abc123def456
 {code}
 would produce the tokens:
 {code}
 abc123, abc, 123, def456, def, 456
 {code}
 Multiple patterns can be applied, eg these patterns could be used for 
 camelCase analysis:
 {code}
 ([A-Z]{2,}),
 (?![A-Z])([A-Z][a-z]+),
 (?:^|\\b|(?=[0-9_])|(?=[A-Z]{2}))([a-z]+),
 ([0-9]+)
 {code}
 When matched against the string letsPartyLIKEits1999_dude, they would 
 produce the tokens:
 {code}
 lets, Party, LIKE, its, 1999, dude
 {code}
 If no token is emitted, the original token is preserved. 
 If the preserveOriginal flag is true, it will output the full original token 
 (ie letsPartyLIKEits1999_dude) in addition to any matching tokens (but in 
 this case, if a matching token is identical to the original, it will only 
 emit one copy of the full token).
 Multiple patterns are required to allow overlapping captures, but also means 
 that patterns are less dense and easier to understand.
 This is my first Java code, so apologies if I'm doing something stupid.

--
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-4766) Pattern token filter which emits a token for every capturing group


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

Simon Willnauer updated LUCENE-4766:


Attachment: LUCENE-4766.patch

argh... I missed svn add... here is the right patch

 Pattern token filter which emits a token for every capturing group
 --

 Key: LUCENE-4766
 URL: https://issues.apache.org/jira/browse/LUCENE-4766
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.1
Reporter: Clinton Gormley
Assignee: Simon Willnauer
Priority: Minor
  Labels: analysis, feature, lucene
 Fix For: 4.3

 Attachments: LUCENE-4766.patch, LUCENE-4766.patch, LUCENE-4766.patch, 
 LUCENE-4766.patch, LUCENE-4766.patch


 The PatternTokenizer either functions by splitting on matches, or allows you 
 to specify a single capture group.  This is insufficient for my needs. Quite 
 often I want to capture multiple overlapping tokens in the same position.
 I've written a pattern token filter which accepts multiple patterns and emits 
 tokens for every capturing group that is matched in any pattern.
 Patterns are not anchored to the beginning and end of the string, so each 
 pattern can produce multiple matches.
 For instance a pattern like :
 {code}
 (([a-z]+)(\d*))
 {code}
 when matched against: 
 {code}
 abc123def456
 {code}
 would produce the tokens:
 {code}
 abc123, abc, 123, def456, def, 456
 {code}
 Multiple patterns can be applied, eg these patterns could be used for 
 camelCase analysis:
 {code}
 ([A-Z]{2,}),
 (?![A-Z])([A-Z][a-z]+),
 (?:^|\\b|(?=[0-9_])|(?=[A-Z]{2}))([a-z]+),
 ([0-9]+)
 {code}
 When matched against the string letsPartyLIKEits1999_dude, they would 
 produce the tokens:
 {code}
 lets, Party, LIKE, its, 1999, dude
 {code}
 If no token is emitted, the original token is preserved. 
 If the preserveOriginal flag is true, it will output the full original token 
 (ie letsPartyLIKEits1999_dude) in addition to any matching tokens (but in 
 this case, if a matching token is identical to the original, it will only 
 emit one copy of the full token).
 Multiple patterns are required to allow overlapping captures, but also means 
 that patterns are less dense and easier to understand.
 This is my first Java code, so apologies if I'm doing something stupid.

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work

2013-04-24 Thread Stefan Matheis (steffkes) (JIRA)


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

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

Sam, Alin .. perhaps it'd be good to compare underlying values to see if there 
is a common way to handle this for all situations.

for me (solr's example package with shipped jetty), i get these values placed 
in the initial page of the UI:
{code}app_config.solr_path = '\/solr';
app_config.core_admin_path = '\/admin\/cores';{code}

{{solr_path}} is defined by {{HttpServletRequest.getContextPath()}} and 
{{core_admin_path}} by {{CoreContainer.getAdminPath()}}

From Sam's Comment i'd say the latter seems to be correct, but the former is 
missing the prefix. I don't really know how the {{HttpServletRequest}} 
determines which is the right context .. !?

 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-4766) Pattern token filter which emits a token for every capturing group

2013-04-24 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-4766:
--

+1

 Pattern token filter which emits a token for every capturing group
 --

 Key: LUCENE-4766
 URL: https://issues.apache.org/jira/browse/LUCENE-4766
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.1
Reporter: Clinton Gormley
Assignee: Simon Willnauer
Priority: Minor
  Labels: analysis, feature, lucene
 Fix For: 4.3

 Attachments: LUCENE-4766.patch, LUCENE-4766.patch, LUCENE-4766.patch, 
 LUCENE-4766.patch, LUCENE-4766.patch


 The PatternTokenizer either functions by splitting on matches, or allows you 
 to specify a single capture group.  This is insufficient for my needs. Quite 
 often I want to capture multiple overlapping tokens in the same position.
 I've written a pattern token filter which accepts multiple patterns and emits 
 tokens for every capturing group that is matched in any pattern.
 Patterns are not anchored to the beginning and end of the string, so each 
 pattern can produce multiple matches.
 For instance a pattern like :
 {code}
 (([a-z]+)(\d*))
 {code}
 when matched against: 
 {code}
 abc123def456
 {code}
 would produce the tokens:
 {code}
 abc123, abc, 123, def456, def, 456
 {code}
 Multiple patterns can be applied, eg these patterns could be used for 
 camelCase analysis:
 {code}
 ([A-Z]{2,}),
 (?![A-Z])([A-Z][a-z]+),
 (?:^|\\b|(?=[0-9_])|(?=[A-Z]{2}))([a-z]+),
 ([0-9]+)
 {code}
 When matched against the string letsPartyLIKEits1999_dude, they would 
 produce the tokens:
 {code}
 lets, Party, LIKE, its, 1999, dude
 {code}
 If no token is emitted, the original token is preserved. 
 If the preserveOriginal flag is true, it will output the full original token 
 (ie letsPartyLIKEits1999_dude) in addition to any matching tokens (but in 
 this case, if a matching token is identical to the original, it will only 
 emit one copy of the full token).
 Multiple patterns are required to allow overlapping captures, but also means 
 that patterns are less dense and easier to understand.
 This is my first Java code, so apologies if I'm doing something stupid.

--
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-4766) Pattern token filter which emits a token for every capturing group


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

Commit Tag Bot commented on LUCENE-4766:


[trunk commit] simonw
http://svn.apache.org/viewvc?view=revisionrevision=1471347

LUCENE-4766: Added a PatternCaptureGroupTokenFilter that uses Java regexes to 
emit multiple tokens one for each capture group in one or more patterns

 Pattern token filter which emits a token for every capturing group
 --

 Key: LUCENE-4766
 URL: https://issues.apache.org/jira/browse/LUCENE-4766
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.1
Reporter: Clinton Gormley
Assignee: Simon Willnauer
Priority: Minor
  Labels: analysis, feature, lucene
 Fix For: 4.3

 Attachments: LUCENE-4766.patch, LUCENE-4766.patch, LUCENE-4766.patch, 
 LUCENE-4766.patch, LUCENE-4766.patch


 The PatternTokenizer either functions by splitting on matches, or allows you 
 to specify a single capture group.  This is insufficient for my needs. Quite 
 often I want to capture multiple overlapping tokens in the same position.
 I've written a pattern token filter which accepts multiple patterns and emits 
 tokens for every capturing group that is matched in any pattern.
 Patterns are not anchored to the beginning and end of the string, so each 
 pattern can produce multiple matches.
 For instance a pattern like :
 {code}
 (([a-z]+)(\d*))
 {code}
 when matched against: 
 {code}
 abc123def456
 {code}
 would produce the tokens:
 {code}
 abc123, abc, 123, def456, def, 456
 {code}
 Multiple patterns can be applied, eg these patterns could be used for 
 camelCase analysis:
 {code}
 ([A-Z]{2,}),
 (?![A-Z])([A-Z][a-z]+),
 (?:^|\\b|(?=[0-9_])|(?=[A-Z]{2}))([a-z]+),
 ([0-9]+)
 {code}
 When matched against the string letsPartyLIKEits1999_dude, they would 
 produce the tokens:
 {code}
 lets, Party, LIKE, its, 1999, dude
 {code}
 If no token is emitted, the original token is preserved. 
 If the preserveOriginal flag is true, it will output the full original token 
 (ie letsPartyLIKEits1999_dude) in addition to any matching tokens (but in 
 this case, if a matching token is identical to the original, it will only 
 emit one copy of the full token).
 Multiple patterns are required to allow overlapping captures, but also means 
 that patterns are less dense and easier to understand.
 This is my first Java code, so apologies if I'm doing something stupid.

--
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-4766) Pattern token filter which emits a token for every capturing group


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

Commit Tag Bot commented on LUCENE-4766:


[branch_4x commit] simonw
http://svn.apache.org/viewvc?view=revisionrevision=1471352

LUCENE-4766: Added a PatternCaptureGroupTokenFilter that uses Java regexes to 
emit multiple tokens one for each capture group in one or more patterns

 Pattern token filter which emits a token for every capturing group
 --

 Key: LUCENE-4766
 URL: https://issues.apache.org/jira/browse/LUCENE-4766
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.1
Reporter: Clinton Gormley
Assignee: Simon Willnauer
Priority: Minor
  Labels: analysis, feature, lucene
 Fix For: 4.3

 Attachments: LUCENE-4766.patch, LUCENE-4766.patch, LUCENE-4766.patch, 
 LUCENE-4766.patch, LUCENE-4766.patch


 The PatternTokenizer either functions by splitting on matches, or allows you 
 to specify a single capture group.  This is insufficient for my needs. Quite 
 often I want to capture multiple overlapping tokens in the same position.
 I've written a pattern token filter which accepts multiple patterns and emits 
 tokens for every capturing group that is matched in any pattern.
 Patterns are not anchored to the beginning and end of the string, so each 
 pattern can produce multiple matches.
 For instance a pattern like :
 {code}
 (([a-z]+)(\d*))
 {code}
 when matched against: 
 {code}
 abc123def456
 {code}
 would produce the tokens:
 {code}
 abc123, abc, 123, def456, def, 456
 {code}
 Multiple patterns can be applied, eg these patterns could be used for 
 camelCase analysis:
 {code}
 ([A-Z]{2,}),
 (?![A-Z])([A-Z][a-z]+),
 (?:^|\\b|(?=[0-9_])|(?=[A-Z]{2}))([a-z]+),
 ([0-9]+)
 {code}
 When matched against the string letsPartyLIKEits1999_dude, they would 
 produce the tokens:
 {code}
 lets, Party, LIKE, its, 1999, dude
 {code}
 If no token is emitted, the original token is preserved. 
 If the preserveOriginal flag is true, it will output the full original token 
 (ie letsPartyLIKEits1999_dude) in addition to any matching tokens (but in 
 this case, if a matching token is identical to the original, it will only 
 emit one copy of the full token).
 Multiple patterns are required to allow overlapping captures, but also means 
 that patterns are less dense and easier to understand.
 This is my first Java code, so apologies if I'm doing something stupid.

--
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-4766) Pattern token filter which emits a token for every capturing group


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

Simon Willnauer resolved LUCENE-4766.
-

   Resolution: Fixed
Fix Version/s: (was: 4.3)
   4.4
   5.0

committed, thanks clinton

 Pattern token filter which emits a token for every capturing group
 --

 Key: LUCENE-4766
 URL: https://issues.apache.org/jira/browse/LUCENE-4766
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.1
Reporter: Clinton Gormley
Assignee: Simon Willnauer
Priority: Minor
  Labels: analysis, feature, lucene
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4766.patch, LUCENE-4766.patch, LUCENE-4766.patch, 
 LUCENE-4766.patch, LUCENE-4766.patch


 The PatternTokenizer either functions by splitting on matches, or allows you 
 to specify a single capture group.  This is insufficient for my needs. Quite 
 often I want to capture multiple overlapping tokens in the same position.
 I've written a pattern token filter which accepts multiple patterns and emits 
 tokens for every capturing group that is matched in any pattern.
 Patterns are not anchored to the beginning and end of the string, so each 
 pattern can produce multiple matches.
 For instance a pattern like :
 {code}
 (([a-z]+)(\d*))
 {code}
 when matched against: 
 {code}
 abc123def456
 {code}
 would produce the tokens:
 {code}
 abc123, abc, 123, def456, def, 456
 {code}
 Multiple patterns can be applied, eg these patterns could be used for 
 camelCase analysis:
 {code}
 ([A-Z]{2,}),
 (?![A-Z])([A-Z][a-z]+),
 (?:^|\\b|(?=[0-9_])|(?=[A-Z]{2}))([a-z]+),
 ([0-9]+)
 {code}
 When matched against the string letsPartyLIKEits1999_dude, they would 
 produce the tokens:
 {code}
 lets, Party, LIKE, its, 1999, dude
 {code}
 If no token is emitted, the original token is preserved. 
 If the preserveOriginal flag is true, it will output the full original token 
 (ie letsPartyLIKEits1999_dude) in addition to any matching tokens (but in 
 this case, if a matching token is identical to the original, it will only 
 emit one copy of the full token).
 Multiple patterns are required to allow overlapping captures, but also means 
 that patterns are less dense and easier to understand.
 This is my first Java code, so apologies if I'm doing something stupid.

--
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: [jira] [Created] (SOLR-4755) Solr cloud 4.1.0 - core creation problem

2013-04-24 Thread Erick Erickson

Currently, I think it's a bit ragged. You need to upconfig, but the
tool to do that is ZkCli, something like:

java -classpath example/solr-webapp/WEB-INF/lib/*
org.apache.solr.cloud.ZkCLI -cmd upconfig -zkhost 127.0.0.1:9983
-confdir example/solr/mycoreconf/conf -confname mycore

I took a very brief look around the solrj code
(org.apache.solr.common.cloud) and it looks like that's for reading
more than writing.

So (and someone correct me if I'm wrong), it looks like uploading
configurations isn't supported from within SolrJ.

Best
Erick

On Wed, Apr 24, 2013 at 4:03 AM, Vijay Tiwary (JIRA) j...@apache.org wrote:
 Vijay Tiwary created SOLR-4755:
 --

  Summary: Solr cloud 4.1.0 - core creation problem
  Key: SOLR-4755
  URL: https://issues.apache.org/jira/browse/SOLR-4755
  Project: Solr
   Issue Type: Test
   Components: clients - java
 Affects Versions: 4.1
  Environment: linux
 Reporter: Vijay Tiwary
 Priority: Critical


 I am trying to create core dynamically through my java appliction in solr 
 cloud having two shard.


 CloudSolrServer cloudSolrServer = new CloudSolrServer(localhost:9983, 
 new LBHttpSolrServer  (http://localhost:8983/solr;));
 CoreAdminRequest.Create req = new CoreAdminRequest.Create() {

  private static final long serialVersionUID = 
 -8825247378713661625L;

 @Override public SolrParams getParams() {
 ModifiableSolrParams modifiableSolrParams =   
(ModifiableSolrParams) super.getParams();
 
 modifiableSolrParams.set(collection.configName, mycore);
 return modifiableSolrParams;
 }
 };

 req.setInstanceDir(/solr/master/mycorepath);
 req.setCollection(mycore);

 CoreAdminResponse res = req.process(cloudSolrServer.getLbServer());



 However i am getting the error:
 **Specified config does not exist in ZooKeeper:mycore**

 When I checked in the solr admin console I found the collection mycore is 
 not completely created[i.e it does not have the folder symbol] and there is 
 no config with the name mycore.

 **How do I go about this problem. What is the standard way for creating core 
 dynamically in a 2 shard solr cloud (solr 4.1.0)?**




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

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


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

Re: Contributing the Korean Analyzer

2013-04-24 Thread Christian Moen

Hello Soomyung,

Thanks a lot for this.  This is very good news.

Let's await the PMC Chair's suggestion on next steps.  See LUCENE-3305 to get 
an idea how the process was for Japanese.

If the process goes well, I'm happy to see how I can set aside some time after 
Lucene Revolution to work on integrating this.

Best regards,

Christian Moen
アティリカ株式会社
http://www.atilika.com

On Apr 24, 2013, at 7:40 PM, 이수명 smlee0...@gmail.com wrote:

 Hello Christian.
 
 Thanks for your reply.
 I'm happy to hear about a code grant process.
 
 To make the dictionaries, I collected words itself and word features from 
 books and internet.
 And I organized all of the information that I collected to make the korean 
 morphological analyzer.
 Therefore the dictionaries is that I made.
 
 I think It is enough to attach a file(License Notice) that describe on where 
 the dictionaries originate from and the kind of licensing (Apache License 
 2.0).
 
 If it is not enough, please leave me a message and give me some guide.
 
 thanks.
 
 Soomyung Lee
 
 
 2013/4/24 Christian Moen c...@atilika.com
 Hello SooMyung,
 
 Thanks a lot!  It will be great to get Korean supported out-of-the-box in 
 Lucene/Solr.
 
 In terms of process, I'll leave this to Steve Rowe, PMC Chair, to comment on, 
 but a code grant process sounds likely.
 
 I'm seeing that the code itself has an Apache License 2.0, but could you 
 elaborate on where the dictionaries originate from and what kind of licensing 
 terms that are applicable?
 
 Many thanks,
 
 
 Christian Moen
 
 On Apr 24, 2013, at 2:05 PM, smlee0...@gmail.com wrote:
 
 Hello,
 
 I've developed the Korean Analyzer and distributed it since 2008.
 Many people who use lucene with korean use it.
 
 I posted it to the sourceforge (http://sourceforge.net/projects/lucenekorean)
 Here is the cvs address
 d:pserver:anonym...@lucenekorean.cvs.sourceforge.net:/cvsroot/lucenekorean
 
 KoreanAnalyzer consists of Korean Morphological Analyzer, Korean Dictionary 
 and Korean Filter.
 When using lucene with korean, One thinks of CJK Analyzer.
 But CJK Analyzer is improper for korean.
 
 Korean has a specific characteristic and is needed to analyze morpheme when 
 extracting the index keyword.
 Korean Analyzer has solved the problem with the Korean Morphological 
 Analyzer.
 
 Korean Analyzer has also the feature of spliting compound noun.
 
 Now, I want to contribute the korean analyzer to the lucene project.
 Please let me know how to contribute it.
 
 If you want to check the source code, please visit the sourceforge cvs 
 repository.
 
 Best regards.
 -- 
 SooMyung Lee
 Director of Research Center
 Argonet co. ltd,
 
 Manager of Luene Korean Analyzer
 http://korlucene.naver.com
 
 Contact: +82-10-6480-5710
 
 
 
 
 -- 
 SooMyung Lee
 Director of Research Center
 Argonet co. ltd,
 
 Manager of Luene Korean Analyzer
 http://korlucene.naver.com
 
 Contact: +82-10-6480-5710


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

Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 244 - Still Failing

2013-04-24 Thread Michael McCandless

This reproduces ... I'm digging.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Apr 24, 2013 at 2:29 AM, Apache Jenkins Server 
jenk...@builds.apache.org wrote:

 Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/244/

 1 tests failed.
 REGRESSION:
  org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic

 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest):
 Insane FieldCache usage(s) found expected:0 but was:2

 Stack Trace:
 java.lang.AssertionError:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest):
 Insane FieldCache usage(s) found expected:0 but was:2
 at
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at java.lang.Thread.run(Thread.java:722)




 Build Log:
 [...truncated 6904 lines...]
 [junit4:junit4] Suite:
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest
 [junit4:junit4]   2 *** BEGIN
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest):
 Insane FieldCache usage(s) ***
 [junit4:junit4]   2 VALUEMISMATCH: Multiple distinct value objects for
 ParallelAtomicReader(_0(5.0):C3)+id
 [junit4:junit4]   2'ParallelAtomicReader(_0(5.0):C3)'='id',class
 org.apache.lucene.index.SortedDocValues,0.5=org.apache.lucene.search.FieldCacheImpl$SortedDocValuesImpl#386041791
 (size =~ 232 bytes)
 [junit4:junit4]   2
  
 'ParallelAtomicReader(_0(5.0):C3)'='id',int,org.apache.lucene.search.FieldCache.DEFAULT_INT_PARSER=org.apache.lucene.search.FieldCacheImpl$IntsFromArray#140912913
 (size =~ 48 bytes)
 [junit4:junit4]   2
  
 'ParallelAtomicReader(_0(5.0):C3)'='id',int,null=org.apache.lucene.search.FieldCacheImpl$IntsFromArray#140912913
 (size =~ 48 bytes)

Re: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-24 Thread Martijn v Groningen

+1, smoker is happy


On 24 April 2013 10:03, Tommaso Teofili tommaso.teof...@gmail.com wrote:

 +1, smoke tests pass.

 Tommaso


 2013/4/23 Simon Willnauer simon.willna...@gmail.com

 Here is a new RC candidate...


 http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/

 here is my +1

 thanks for voting...

 simon

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





-- 
Met vriendelijke groet,

Martijn van Groningen

[jira] [Created] (LUCENE-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves

Michael McCandless created LUCENE-4953:
--

 Summary: readerClosedListener is not invoked for 
ParallelCompositeReader's leaves
 Key: LUCENE-4953
 URL: https://issues.apache.org/jira/browse/LUCENE-4953
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, 4.4


There was a test failure last night:

{noformat}
1 tests failed.
REGRESSION:  
org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic

Error Message:
testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): Insane 
FieldCache usage(s) found expected:0 but was:2

Stack Trace:
java.lang.AssertionError: 
testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): Insane 
FieldCache usage(s) found expected:0 but was:2
at 
__randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)




Build Log:
[...truncated 6904 lines...]
[junit4:junit4] Suite: 
org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest
[junit4:junit4]   2 *** BEGIN 
testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): Insane 
FieldCache usage(s) ***
[junit4:junit4]   2 VALUEMISMATCH: Multiple distinct value objects for 
ParallelAtomicReader(_0(5.0):C3)+id
[junit4:junit4]   2'ParallelAtomicReader(_0(5.0):C3)'='id',class 
org.apache.lucene.index.SortedDocValues,0.5=org.apache.lucene.search.FieldCacheImpl$SortedDocValuesImpl#386041791
 (size =~ 232 bytes)
[junit4:junit4]   2
'ParallelAtomicReader(_0(5.0):C3)'='id',int,org.apache.lucene.search.FieldCache.DEFAULT_INT_PARSER=org.apache.lucene.search.FieldCacheImpl$IntsFromArray#140912913
 (size =~ 48

[jira] [Updated] (LUCENE-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Michael McCandless updated LUCENE-4953:
---

Attachment: LUCENE-4953.patch

Test case showing the root cause of the failure ...

I think we need to fix ParallelCompositeReader so that it actually closes the 
subReaders it creates?

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

 Key: LUCENE-4953
 URL: https://issues.apache.org/jira/browse/LUCENE-4953
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at java.lang.Thread.run(Thread.java:722)
 Build Log:
 [...truncated 6904 lines...]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest
 [junit4:junit4]   2 *** BEGIN 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) ***

[jira] [Commented] (SOLR-3781) when wiring Solr into a larger web application which controls the web context root,something can't work

2013-04-24 Thread Alin Simionoiu (JIRA)


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

Alin Simionoiu commented on SOLR-3781:
--

here's my setup (and initial page values).

i have solr inside a larger web application which starts in the root context 
(this part i believe is critical). in my web.xml i have my servlets and 
filters, and i copied more or less the solr web.xml context. 

i want solr to work from, let's say '/mysolr'. i'm changing the value here, not 
to be confused with the default '/solr'
for the SolrRequstFilter i setup: path-prefix = /mysolr and the url-pattern = 
/mysolr/*

in the initial page of the UI, i have:
app_config.solr_path = '';
app_config.core_admin_path = '\/admin\/cores';

LoadAdminUiServlet seems to set the app_config.solr_path to 
request.getContextPath(), and since my application works from root context it 
kind of makes sense for solr_path to be '' (maybe is '\/' and it gets removed 
by the code later on). This will make all the calls inside the admin.html to go 
against, let's say /admin/cores (invalid URL for me) instead of expected 
/mysolr/admin/cores

if i provide my own copy of LoadAdminUiServlet, which sets 
app_config.solr_path='\/mysolr', than the admin.html calls will double that for 
some reasons, '/mysolr/mysolr/admin/cores' instead of '/mysolr/admin/cores', i 
can't figure this one out.

(as a hack i'm also using a copy of SolrRequestFilter which removes the double 
prefix if found, and now admin.html kind of works. the only thing that i still 
have to figure out is the zookeeper part, that one still doesn't work, not sure 
why is going against /zookeeper instead of /mysolr/zookeeper).

i'm just using '/admin/cores' as examples here, logging and all the other URL's 
have the same problem.

Does this makes more sense now?





 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-4954) LuceneTestFramework fails to catch temporary FieldCache insanity

Michael McCandless created LUCENE-4954:
--

 Summary: LuceneTestFramework fails to catch temporary FieldCache 
insanity
 Key: LUCENE-4954
 URL: https://issues.apache.org/jira/browse/LUCENE-4954
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, 4.4


Ever since we added readerClosedListeners to evict FieldCache entries, LTC will 
no longer detect insanity as long as the test closes all readers leading to 
insanity ...

So this has weakened our testing of catching accidental insanity producing code.

To fix this I think we could tap into FieldCacheImpl.setInfoStream ... and 
ensure the test didn't print anything to it.

This was a spinoff from LUCENE-4953, where that test 
(AllGroupHeadsCollectorTest) is always producing insanity, but then because of 
a bug the FC eviction wasn't working right, and LTC then detected the insanity.

--
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-4947) Java implementation (and improvement) of Levenshtein associated lexicon automata

2013-04-24 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on LUCENE-4947:

bq. I assumed you guys would simply grab the tarballs from the GitHub links I
posted.

Okay, cool, I think that will work.

Do you intend for these two projects to live on after they've been incorporated
into Lucene? If so, then I'll fork them on Github and start making license
header changes - ALv2; Kevin, do you give your consent for me to change the
license headers in all files to point to ALv2?

If you don't intend for these two projects to continue life separately from
Lucene, then I think it will make sense for you to do the license changes
in-place yourself, Kevin. Alternatively, you could grant write access to
someone else to do the work. Please let us know.

I have started the IP clearance form. It's online now at
[http://incubator.apache.org/ip-clearance/lucene-levenshtein-automaton-mdag.html].

Java implementation (and improvement) of Levenshtein associated lexicon
automata
--

Key: LUCENE-4947
URL: https://issues.apache.org/jira/browse/LUCENE-4947
Project: Lucene - Core
Issue Type: Improvement
Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0, 4.1, 4.2, 4.2.1
Reporter: Kevin Lawson

I was encouraged by Mike McCandless to open an issue concerning this after I
contacted him privately about it. Thanks Mike!
I'd like to submit my Java implementation of the Levenshtein Automaton as a
homogenous replacement for the current heterogenous, multi-component
implementation in Lucene.
Benefits of upgrading include
- Reduced code complexity
- Better performance from components that were previously implemented in
Python
- Support for on-the-fly dictionary-automaton manipulation (if you wish to
use my dictionary-automaton implementation)
The code for all the components is well structured, easy to follow, and
extensively commented. It has also been fully tested for correct
functionality and performance.
The levenshtein automaton implementation (along with the required MDAG
reference) can be found in my LevenshteinAutomaton Java library here:
https://github.com/klawson88/LevenshteinAutomaton.
The minimalistic directed acyclic graph (MDAG) which the automaton code uses
to store and step through word sets can be found here:
https://github.com/klawson88/MDAG
*Transpositions aren't currently implemented. I hope the comment filled,
editing-friendly code combined with the fact that the section in the Mihov
paper detailing transpositions is only 2 pages makes adding the functionality
trivial.
*As a result of support for on-the-fly manipulation, the MDAG
(dictionary-automaton) creation process incurs a slight speed penalty. In
order to have the best of both worlds, i'd recommend the addition of a
constructor which only takes sorted input. The complete, easy to follow
pseudo-code for the simple procedure can be found in the first article I
linked under the references section in the MDAG repository)

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work


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

Sam Kass updated SOLR-3781:
---

Attachment: LoadAdminUiServlet_take2.patch

Based on Alin and Stefan's comment, I added the prefix to the contextPath and 
now everything seems to work.  The take2 patch alone-- with no changes to any 
.js files-- seems to solve the problem.  (I now explicitly parse out the prefix 
before the /admin.html and add it to the context path as well as the initial 
get resource call.)

 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, LoadAdminUiServlet_take2.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work


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

Sam Kass updated SOLR-3781:
---

Attachment: web.xml

For testing purposes, I'm including my web.xml file that I tested my patch 
with, which is a minimal modification of the one that comes with solr-4.2.1's 
example.  I use the /test prefix (instead of the suggested /solr prefix) to 
make it clearer where it's getting inserted.  As stated in the web.xml, all the 
css, img, js, tpl directories, plus admin.html, must be placed into a test 
directory under solr-webapp/webapp.

 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work


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

Sam Kass edited comment on SOLR-3781 at 4/24/13 2:51 PM:
-

For testing purposes, I'm including my web.xml file that I tested my patch 
with, which is a minimal modification of the one that comes with solr-4.2.1's 
example.  I use the /test prefix (instead of the suggested /solr prefix) to 
make it clearer where it's getting inserted.  As stated in the web.xml, all the 
css, img, js, tpl directories, plus admin.html, must be moved into a test 
directory under solr-webapp/webapp.

  was (Author: samkass):
For testing purposes, I'm including my web.xml file that I tested my patch 
with, which is a minimal modification of the one that comes with solr-4.2.1's 
example.  I use the /test prefix (instead of the suggested /solr prefix) to 
make it clearer where it's getting inserted.  As stated in the web.xml, all the 
css, img, js, tpl directories, plus admin.html, must be placed into a test 
directory under solr-webapp/webapp.
  
 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work


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

Sam Kass edited comment on SOLR-3781 at 4/24/13 2:52 PM:
-

For testing purposes, I'm including my web.xml file that I tested my patch 
with, which is a minimal modification of the one that comes with solr-4.2.1's 
example.  I use the /test prefix (instead of the suggested /solr prefix) to 
make it clearer where it's getting inserted.  As stated in the web.xml, all the 
css, img, js, tpl directories, plus admin.html, must be moved into a test 
directory under solr-webapp/webapp.

Note that the changes to web.xml are NOT part of the suggested changes, just 
for testing the actual patch.

  was (Author: samkass):
For testing purposes, I'm including my web.xml file that I tested my patch 
with, which is a minimal modification of the one that comes with solr-4.2.1's 
example.  I use the /test prefix (instead of the suggested /solr prefix) to 
make it clearer where it's getting inserted.  As stated in the web.xml, all the 
css, img, js, tpl directories, plus admin.html, must be moved into a test 
directory under solr-webapp/webapp.
  
 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work


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

Sam Kass commented on SOLR-3781:


Also, this bug's Component should probably be web gui.


 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-4947) Java implementation (and improvement) of Levenshtein associated lexicon automata

2013-04-24 Thread Christian Moen (JIRA)


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

Christian Moen commented on LUCENE-4947:


Kevin,

I think it's best that you do the license change yourself and that we don't 
have any active role in making the change since you are the only person 
entitled to make the change.

This change can be done by using the below header on all the source code and 
other relevant text files:

{noformat}
/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the License); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an AS IS BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
{noformat}

After this has been done, please make a tarball and attach it to this JIRA and 
indicate that this is the code you wish to grant and also inform us about the 
MD5 hash of the tarball.  (This will go into the IP-clearance document and will 
be used to identify the codebase.)

It's a good idea to also use this MD5 hash as part of Exhibit A in the 
[software-grant.txt|http://www.apache.org/licenses/software-grant.txt] 
agreement unless you have signed and submitted this already.  (If you donate 
the code yourself by attaching it to the JIRA as described above, I believe the 
hashes not being part of Exhibit A is acceptable.)

Please feel free to add your comments, Steve.


 Java implementation (and improvement) of Levenshtein  associated lexicon 
 automata
 --

 Key: LUCENE-4947
 URL: https://issues.apache.org/jira/browse/LUCENE-4947
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0, 4.1, 4.2, 4.2.1
Reporter: Kevin Lawson

 I was encouraged by Mike McCandless to open an issue concerning this after I 
 contacted him privately about it. Thanks Mike!
 I'd like to submit my Java implementation of the Levenshtein Automaton as a 
 homogenous replacement for the current heterogenous, multi-component 
 implementation in Lucene.
 Benefits of upgrading include 
 - Reduced code complexity
 - Better performance from components that were previously implemented in 
 Python
 - Support for on-the-fly dictionary-automaton manipulation (if you wish to 
 use my dictionary-automaton implementation)
 The code for all the components is well structured, easy to follow, and 
 extensively commented. It has also been fully tested for correct 
 functionality and performance.
 The levenshtein automaton implementation (along with the required MDAG 
 reference) can be found in my LevenshteinAutomaton Java library here: 
 https://github.com/klawson88/LevenshteinAutomaton.
 The minimalistic directed acyclic graph (MDAG) which the automaton code uses 
 to store and step through word sets can be found here: 
 https://github.com/klawson88/MDAG
 *Transpositions aren't currently implemented. I hope the comment filled, 
 editing-friendly code combined with the fact that the section in the Mihov 
 paper detailing transpositions is only 2 pages makes adding the functionality 
 trivial.
 *As a result of support for on-the-fly manipulation, the MDAG 
 (dictionary-automaton) creation process incurs a slight speed penalty. In 
 order to have the best of both worlds, i'd recommend the addition of a 
 constructor which only takes sorted input. The complete, easy to follow 
 pseudo-code for the simple procedure can be found in the first article I 
 linked under the references section in the MDAG repository)

--
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-4756) Change some of our existing tests to use the new solr.xml format and core discovery by directory structure.

Mark Miller created SOLR-4756:
-

 Summary: Change some of our existing tests to use the new solr.xml 
format and core discovery by directory structure.
 Key: SOLR-4756
 URL: https://issues.apache.org/jira/browse/SOLR-4756
 Project: Solr
  Issue Type: Bug
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] (LUCENE-4947) Java implementation (and improvement) of Levenshtein associated lexicon automata

2013-04-24 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on LUCENE-4947:


bq. I think it's best that you do the license change yourself and that we don't 
have any active role in making the change since you are the only person 
entitled to make the change.

+1

bq. After this has been done, please make a tarball and attach it to this JIRA 
and indicate that this is the code you wish to grant and also inform us about 
the MD5 hash of the tarball. (This will go into the IP-clearance document and 
will be used to identify the codebase.)

I and Dawid had been advocating using Github for this, but I agree with 
Christian: a tarball attached to this issue by you, [~klawson88], will remove 
all ambiguity about what is being donated and by whom.  Also, Github is not 
under ASF control, and in the future if that business goes under, the ASF will 
lose the history of this donation. 


 Java implementation (and improvement) of Levenshtein  associated lexicon 
 automata
 --

 Key: LUCENE-4947
 URL: https://issues.apache.org/jira/browse/LUCENE-4947
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0, 4.1, 4.2, 4.2.1
Reporter: Kevin Lawson

 I was encouraged by Mike McCandless to open an issue concerning this after I 
 contacted him privately about it. Thanks Mike!
 I'd like to submit my Java implementation of the Levenshtein Automaton as a 
 homogenous replacement for the current heterogenous, multi-component 
 implementation in Lucene.
 Benefits of upgrading include 
 - Reduced code complexity
 - Better performance from components that were previously implemented in 
 Python
 - Support for on-the-fly dictionary-automaton manipulation (if you wish to 
 use my dictionary-automaton implementation)
 The code for all the components is well structured, easy to follow, and 
 extensively commented. It has also been fully tested for correct 
 functionality and performance.
 The levenshtein automaton implementation (along with the required MDAG 
 reference) can be found in my LevenshteinAutomaton Java library here: 
 https://github.com/klawson88/LevenshteinAutomaton.
 The minimalistic directed acyclic graph (MDAG) which the automaton code uses 
 to store and step through word sets can be found here: 
 https://github.com/klawson88/MDAG
 *Transpositions aren't currently implemented. I hope the comment filled, 
 editing-friendly code combined with the fact that the section in the Mihov 
 paper detailing transpositions is only 2 pages makes adding the functionality 
 trivial.
 *As a result of support for on-the-fly manipulation, the MDAG 
 (dictionary-automaton) creation process incurs a slight speed penalty. In 
 order to have the best of both worlds, i'd recommend the addition of a 
 constructor which only takes sorted input. The complete, easy to follow 
 pseudo-code for the simple procedure can be found in the first article I 
 linked under the references section in the MDAG repository)

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work


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

Sam Kass updated SOLR-3781:
---

Attachment: (was: LoadAdminUiServlet_take2.patch)

 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work


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

Sam Kass updated SOLR-3781:
---

Attachment: LoadAdminUiServlet_take2.patch

Original posting of the take2 patch contained incorrect path information on 
the files... fixed it.

 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

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

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

[jira] [Assigned] (SOLR-4718) Allow solr.xml to be stored in zookeeper

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

Mark Miller reassigned SOLR-4718:
-

Assignee: Mark Miller (was: Erick Erickson)

Allow solr.xml to be stored in zookeeper

Key: SOLR-4718
URL: https://issues.apache.org/jira/browse/SOLR-4718
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Mark Miller

So the near-final piece of this puzzle is to make solr.xml be storable in
Zookeeper. Code-wise in terms of Solr, this doesn't look very difficult, I'm
working on it now.
More interesting is how to get the configuration into ZK in the first place,
enhancements to ZkCli? Or boostrap-conf? Other? I'm punting on that for this
patch.
Second level is how to tell Solr to get the file from ZK. Some possibilities:
1 A system prop, -DzkSolrXmlPath=blah where blah is the path _on zk_ where
the file is. Would require -DzkHost or -DzkRun as well.
pros - simple, I can wrap my head around it.
- easy to script
cons - can't run multiple JVMs pointing to different files. Is this
really a problem?
2 New solr.xml element. Something like:
solr
solrcloud
str name=zkHostzkurl/str
str name=zkSolrXmlPathwhatever/str
/solrcloud
solr
Really, this form would hinge on the presence or absence of zkSolrXmlPath.
If present, go up and look for the indicated solr.xml file on ZK. Any
properties in the ZK version would overwrite anything in the local copy.
NOTE: I'm really not very interested in supporting this as an option for
old-style solr.xml unless it's _really_ easy. For instance, what if the local
solr.xml is new-style and the one in ZK is old-style? Or vice-versa? Since
old-style is going away, this doesn't seem like it's worth the effort.
pros - No new mechanisms
cons - once again requires that there be a solr.xml file on each client.
Admittedly for installations that didn't care much about multiple JVMs, it
could be a stock file that didn't change...
For now, I'm going to just manually push solr.xml to ZK, then read it based
on a sysprop. That'll get the structure in place while we debate. Not going
to check this in until there's some consensus though.

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

[jira] [Commented] (SOLR-4718) Allow solr.xml to be stored in zookeeper

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

Mark Miller commented on SOLR-4718:
---

I'm going to take a crack at this. Since this will only be done with the new
solr.xml that does core discovery by directory structure, we need to start
getting some of our tests using that.

Allow solr.xml to be stored in zookeeper

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

[jira] [Commented] (SOLR-4718) Allow solr.xml to be stored in zookeeper

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

Mark Miller commented on SOLR-4718:
---

SOLR-4756 Change some of our existing tests to use the new solr.xml format and
core discovery by directory structure.

Allow solr.xml to be stored in zookeeper

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

[jira] [Commented] (SOLR-4756) Change some of our existing tests to use the new solr.xml format and core discovery by directory structure.

2013-04-24 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-4756:
--

I'm kind of shuddering at the notion of making _all_ of the tests use the new 
format when we stop supporting old-style..

 Change some of our existing tests to use the new solr.xml format and core 
 discovery by directory structure.
 ---

 Key: SOLR-4756
 URL: https://issues.apache.org/jira/browse/SOLR-4756
 Project: Solr
  Issue Type: Bug
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-4756) Change some of our existing tests to use the new solr.xml format and core discovery by directory structure.


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

Mark Miller commented on SOLR-4756:
---

That's why I'm going with one step at a time :) We will get there.

 Change some of our existing tests to use the new solr.xml format and core 
 discovery by directory structure.
 ---

 Key: SOLR-4756
 URL: https://issues.apache.org/jira/browse/SOLR-4756
 Project: Solr
  Issue Type: Bug
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

Re: Contributing the Korean Analyzer

2013-04-24 Thread Steve Rowe

Hi Soomyung,

I agree with Christian, this sounds fantastic!

First, we need to know a couple things:

1. Are you the only author of the code?  We need to get agreement from all 
contributors.  (When I browse CVS on the SourceForge site, the only author I 
see is smlee0818, which I assume is you.)

2. Do you need permission from your employer to make this donation?  If so, 
we'll need your employer to submit a Corporate CLA (Contributor License 
Agreement)[1] before we can accept the donation.

To get started, the first step is creating a Lucene JIRA issue here: 
https://issues.apache.org/jira/browse/LUCENE - you'll need to create an ASF 
JIRA account first if you don't already have one: click the Log In link at 
the top right of the page, then click the Sign up link where it says Not a 
member? Sign up for an account.

Once you've created a JIRA issue, you should make a compressed tarball of 
everything you want to contribute - as far as I can tell, this is everything in 
the lucenekorean sourceforge project in CVS under modules kr.dictionary, 
kr.analysis.4x, and kr.morph - and then attach it to the JIRA issue, with 
the MD5 hash for the tarball in the comment that you provide when you attach 
the tarball to the issue.

Once you've created the JIRA issue and attached your contribution, we can make 
progress on further steps that need to be taken: you should submit an 
individual CLA[2] and a code grant[3], and I (in my role as Lucene PMC chair) 
will be managing the IP clearance process[4][5].

See http://wiki.apache.org/lucene-java/HowToContribute for more information 
about contributing.

I look forward to working with you on this - thank you for contributing!

Steve

[1] http://www.apache.org/licenses/cla-corporate.txt
[1] http://www.apache.org/licenses/icla.txt
[2] http://www.apache.org/licenses/software-grant.txt
[3] http://incubator.apache.org/ip-clearance/index.html
[4] http://incubator.apache.org/ip-clearance/ip-clearance-template.html

On Apr 24, 2013, at 7:00 AM, Christian Moen c...@atilika.com wrote:

 Hello Soomyung,
 
 Thanks a lot for this.  This is very good news.
 
 Let's await the PMC Chair's suggestion on next steps.  See LUCENE-3305 to get 
 an idea how the process was for Japanese.
 
 If the process goes well, I'm happy to see how I can set aside some time 
 after Lucene Revolution to work on integrating this.
 
 Best regards,
 
 Christian Moen
 アティリカ株式会社
 http://www.atilika.com
 
 On Apr 24, 2013, at 7:40 PM, 이수명 smlee0...@gmail.com wrote:
 
 Hello Christian.
 
 Thanks for your reply.
 I'm happy to hear about a code grant process.
 
 To make the dictionaries, I collected words itself and word features from 
 books and internet.
 And I organized all of the information that I collected to make the korean 
 morphological analyzer.
 Therefore the dictionaries is that I made.
 
 I think It is enough to attach a file(License Notice) that describe on where 
 the dictionaries originate from and the kind of licensing (Apache License 
 2.0).
 
 If it is not enough, please leave me a message and give me some guide.
 
 thanks.
 
 Soomyung Lee
 
 
 2013/4/24 Christian Moen c...@atilika.com
 Hello SooMyung,
 
 Thanks a lot!  It will be great to get Korean supported out-of-the-box in 
 Lucene/Solr.
 
 In terms of process, I'll leave this to Steve Rowe, PMC Chair, to comment 
 on, but a code grant process sounds likely.
 
 I'm seeing that the code itself has an Apache License 2.0, but could you 
 elaborate on where the dictionaries originate from and what kind of 
 licensing terms that are applicable?
 
 Many thanks,
 
 
 Christian Moen
 
 On Apr 24, 2013, at 2:05 PM, smlee0...@gmail.com wrote:
 
 Hello,
 
 I've developed the Korean Analyzer and distributed it since 2008.
 Many people who use lucene with korean use it.
 
 I posted it to the sourceforge 
 (http://sourceforge.net/projects/lucenekorean)
 Here is the cvs address
 d:pserver:anonym...@lucenekorean.cvs.sourceforge.net:/cvsroot/lucenekorean
 
 KoreanAnalyzer consists of Korean Morphological Analyzer, Korean Dictionary 
 and Korean Filter.
 When using lucene with korean, One thinks of CJK Analyzer.
 But CJK Analyzer is improper for korean.
 
 Korean has a specific characteristic and is needed to analyze morpheme when 
 extracting the index keyword.
 Korean Analyzer has solved the problem with the Korean Morphological 
 Analyzer.
 
 Korean Analyzer has also the feature of spliting compound noun.
 
 Now, I want to contribute the korean analyzer to the lucene project.
 Please let me know how to contribute it.
 
 If you want to check the source code, please visit the sourceforge cvs 
 repository.
 
 Best regards.
 -- 
 SooMyung Lee
 Director of Research Center
 Argonet co. ltd,
 
 Manager of Luene Korean Analyzer
 http://korlucene.naver.com
 
 Contact: +82-10-6480-5710
 
 
 
 
 -- 
 SooMyung Lee
 Director of Research Center
 Argonet co. ltd,
 
 Manager of Luene Korean Analyzer
 http://korlucene.naver.com
 
 Contact: +82-10-6480-5710

[jira] [Created] (LUCENE-4955) NGramTokenFilter increments positions for each gram

Simon Willnauer created LUCENE-4955:
---

 Summary: NGramTokenFilter increments positions for each gram
 Key: LUCENE-4955
 URL: https://issues.apache.org/jira/browse/LUCENE-4955
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.3
Reporter: Simon Willnauer
 Fix For: 5.0, 4.4


NGramTokenFilter increments positions for each gram rather for the actual token 
which can lead to rather funny problems especially with highlighting. if this 
filter should be used for highlighting is a different story but today this 
seems to be a common practice in many situations to highlight sub-term matches.

I have a test for highlighting that uses ngram failing with a StringIOOB since 
tokens are sorted by position which causes offsets to be mixed up due to ngram 
token filter.

--
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-4955) NGramTokenFilter increments positions for each gram


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

Simon Willnauer updated LUCENE-4955:


Attachment: highlighter-test.patch
LUCENE-4955.patch

here is a patch including the deprecation and version support (I bet somebody 
relies on this behaviour) ...for trunk I will remove the deprecated methods but 
I added it here to make sure I don't miss it. 

the second patch is a test for the highlighter that produces a SIOOB without 
the patch but succeeds with the positions patch.

 NGramTokenFilter increments positions for each gram
 ---

 Key: LUCENE-4955
 URL: https://issues.apache.org/jira/browse/LUCENE-4955
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.3
Reporter: Simon Willnauer
 Fix For: 5.0, 4.4

 Attachments: highlighter-test.patch, LUCENE-4955.patch


 NGramTokenFilter increments positions for each gram rather for the actual 
 token which can lead to rather funny problems especially with highlighting. 
 if this filter should be used for highlighting is a different story but today 
 this seems to be a common practice in many situations to highlight sub-term 
 matches.
 I have a test for highlighting that uses ngram failing with a StringIOOB 
 since tokens are sorted by position which causes offsets to be mixed up due 
 to ngram token filter.

--
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-4955) NGramTokenFilter increments positions for each gram

2013-04-24 Thread Jack Krupansky (JIRA)

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

Jack Krupansky commented on LUCENE-4955:

I think that ngram filter and edge-ngram filter are rather different cases.

With edge-ngram it is abundantly clear that all of the edge ngrams stack up
at the same position (at least for front edge ngrams!). But embedded ngrams
seem more like a stretching out of the token, from one token to a sequence of
tokens. Actually, it is k overlayed sequences, where k = maxGramSize minus
minGramSize plus 1.

I think the solution should be to have a mode which indicates whether the
intent is merely variations (sub-tokens) for the token at the same position
vs. a stretching the token into a sequence of tokens. Maybe call it
expansionMode: stack vs. sequence.

But even for the latter, I would definitely recommend that each of the k
sequences should restart the position at the original token position.

NGramTokenFilter increments positions for each gram
---

Key: LUCENE-4955
URL: https://issues.apache.org/jira/browse/LUCENE-4955
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: 4.3
Reporter: Simon Willnauer
Fix For: 5.0, 4.4

Attachments: highlighter-test.patch, LUCENE-4955.patch

NGramTokenFilter increments positions for each gram rather for the actual
token which can lead to rather funny problems especially with highlighting.
if this filter should be used for highlighting is a different story but today
this seems to be a common practice in many situations to highlight sub-term
matches.
I have a test for highlighting that uses ngram failing with a StringIOOB
since tokens are sorted by position which causes offsets to be mixed up due
to ngram token filter.

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

[jira] [Created] (SOLR-4757) Change the example to use the new solr.xml format and core discovery by directory structure.

Mark Miller created SOLR-4757:
-

 Summary: Change the example to use the new solr.xml format and 
core discovery by directory structure.
 Key: SOLR-4757
 URL: https://issues.apache.org/jira/browse/SOLR-4757
 Project: Solr
  Issue Type: Task
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] [Updated] (SOLR-4756) Change some of our existing tests to use the new solr.xml format and core discovery by directory structure.


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

Mark Miller updated SOLR-4756:
--

Issue Type: Task  (was: Bug)

 Change some of our existing tests to use the new solr.xml format and core 
 discovery by directory structure.
 ---

 Key: SOLR-4756
 URL: https://issues.apache.org/jira/browse/SOLR-4756
 Project: Solr
  Issue Type: Task
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-4756) Change some of our existing tests to use the new solr.xml format and core discovery by directory structure.


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

Commit Tag Bot commented on SOLR-4756:
--

[trunk commit] markrmiller
http://svn.apache.org/viewvc?view=revisionrevision=1471545

SOLR-4756: Change some of our existing tests to use the new solr.xml format and 
core discovery by directory structure.

 Change some of our existing tests to use the new solr.xml format and core 
 discovery by directory structure.
 ---

 Key: SOLR-4756
 URL: https://issues.apache.org/jira/browse/SOLR-4756
 Project: Solr
  Issue Type: Task
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-4756) Change some of our existing tests to use the new solr.xml format and core discovery by directory structure.


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

Commit Tag Bot commented on SOLR-4756:
--

[branch_4x commit] markrmiller
http://svn.apache.org/viewvc?view=revisionrevision=1471546

SOLR-4756: Change some of our existing tests to use the new solr.xml format and 
core discovery by directory structure.

 Change some of our existing tests to use the new solr.xml format and core 
 discovery by directory structure.
 ---

 Key: SOLR-4756
 URL: https://issues.apache.org/jira/browse/SOLR-4756
 Project: Solr
  Issue Type: Task
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] [Created] (SOLR-4758) Zk bootstrapping does not work with the new solr.xml format and core discovery by directory structure.

Mark Miller created SOLR-4758:
-

 Summary: Zk bootstrapping does not work with the new solr.xml 
format and core discovery by directory structure.
 Key: SOLR-4758
 URL: https://issues.apache.org/jira/browse/SOLR-4758
 Project: Solr
  Issue Type: Bug
  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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work

2013-04-24 Thread Alin Simionoiu (JIRA)


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

Alin Simionoiu commented on SOLR-3781:
--

thank you very much Sam, this works perfect for me.

 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-4758) Zk bootstrapping does not work with the new solr.xml format and core discovery by directory structure.


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

Mark Miller commented on SOLR-4758:
---

This is largely test related, stemming from the null corecontainer that is used 
in the ZkCLI tests.

 Zk bootstrapping does not work with the new solr.xml format and core 
 discovery by directory structure.
 --

 Key: SOLR-4758
 URL: https://issues.apache.org/jira/browse/SOLR-4758
 Project: Solr
  Issue Type: Bug
  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] (LUCENE-4880) Difference in offset handling between IndexReader created by MemoryIndex and one created by RAMDirectory

2013-04-24 Thread Tim Allison (JIRA)


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

Tim Allison commented on LUCENE-4880:
-

Thank you!

 Difference in offset handling between IndexReader created by MemoryIndex and 
 one created by RAMDirectory
 

 Key: LUCENE-4880
 URL: https://issues.apache.org/jira/browse/LUCENE-4880
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 4.2
 Environment: Windows 7 (probably irrelevant)
Reporter: Tim Allison
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4880.patch, 
 MemoryIndexVsRamDirZeroLengthTermTest.java


 MemoryIndex skips tokens that have length == 0 when building the index; the 
 result is that it does not increment the token offset (nor does it store the 
 position offsets if that option is set) for tokens of length == 0.  A regular 
 index (via, say, RAMDirectory) does not appear to do this.
 When using the ICUFoldingFilter, it is possible to have a term of zero length 
 (the \u0640 character separated by spaces).  If that occurs in a document, 
 the offsets returned at search time differ between the MemoryIndex and a 
 regular index.  

--
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-3781) when wiring Solr into a larger web application which controls the web context root,something can't work


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

Sam Kass edited comment on SOLR-3781 at 4/24/13 7:48 PM:
-

Also, this bug's Component should probably be web gui.  And can we rename 
this bug to something like Admin UI does not work when wiring Solr into a 
larger web application using a path prefix.  And while I'm at it, target it 
for 4.3?


  was (Author: samkass):
Also, this bug's Component should probably be web gui.

  
 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Michael McCandless updated LUCENE-4953:
---

Attachment: LUCENE-4953.patch

Patch that fixes the test but ...

It causes other test failures, because tests do this:

{noformat}
  searcher = newSearcher(reader);
  ...
  reader.close();
{noformat}

(instead of searcher.getIndexReader().close()).

Ie, today LuceneTestCase.maybeWrapReader never incRefs the incoming reader, but 
with the fix, ParallelCompositeReader now does ... so this leads to failures.

Not sure what to do ...

Maybe instead of this patch, we should just directly invoke the 
readerClosedListeners in ParallelCompositReader.doClose?

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

 Key: LUCENE-4953
 URL: https://issues.apache.org/jira/browse/LUCENE-4953
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at

[jira] [Updated] (SOLR-4757) Change the example to use the new solr.xml format and core discovery by directory structure.


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

Mark Miller updated SOLR-4757:
--

Attachment: SOLR-4757.patch

first patch

 Change the example to use the new solr.xml format and core discovery by 
 directory structure.
 

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

 Attachments: SOLR-4757.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-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Uwe Schindler commented on LUCENE-4953:
---

As discussed in IRC today, like MultiReader/SlowComposite that warps another 
reader, we should no call close() on the subreaders. The problem here is: A 
wrapped slow reader still returns its delegate as core cache key, so the reader 
closed listener works as expected.

The problem here is that the leaves are atomic and the field cache does not get 
the reader closed event. The somehow best fix would be to call 
readerClosedListener for all childs (not leaves!) on close. Theoretically, all 
CompositeReaders that wrap ll childs of other readers should do this (only 
Parallel is currently doing this).

Another idea would be to use incRef and decRef, but that would not affect the 
wrapped atomic readers, so I prefer the previous solution.

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

 Key: LUCENE-4953
 URL: https://issues.apache.org/jira/browse/LUCENE-4953
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at

[jira] [Comment Edited] (LUCENE-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Uwe Schindler edited comment on LUCENE-4953 at 4/24/13 8:58 PM:


As discussed in IRC today, like MultiReader/SlowComposite that warps another 
reader, we should no call close() on the subreaders. The problem here is: E.g., 
A wrapped slow reader still returns its delegate as core cache key, so the 
reader closed listener works as expected, when the child is closed. But PMR 
must not return the inner cache keys, as it wraps them with modifying index 
contents.

The problem here is that the leaves are atomic and the field cache does not get 
the reader closed event. The somehow best fix would be to call 
readerClosedListener for all childs (not leaves!) on doClose. Theoretically, 
all CompositeReaders that wrap ll childs of other readers should do this (only 
Parallel is currently doing this).

Another idea would be to use incRef and decRef, but that would not affect the 
wrapped atomic readers, so I prefer the previous solution.

  was (Author: thetaphi):
As discussed in IRC today, like MultiReader/SlowComposite that warps 
another reader, we should no call close() on the subreaders. The problem here 
is: A wrapped slow reader still returns its delegate as core cache key, so the 
reader closed listener works as expected.

The problem here is that the leaves are atomic and the field cache does not get 
the reader closed event. The somehow best fix would be to call 
readerClosedListener for all childs (not leaves!) on close. Theoretically, all 
CompositeReaders that wrap ll childs of other readers should do this (only 
Parallel is currently doing this).

Another idea would be to use incRef and decRef, but that would not affect the 
wrapped atomic readers, so I prefer the previous solution.
  
 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

 Key: LUCENE-4953
 URL: https://issues.apache.org/jira/browse/LUCENE-4953
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at

[jira] [Updated] (LUCENE-4947) Java implementation (and improvement) of Levenshtein associated lexicon automata

2013-04-24 Thread Kevin Lawson (JIRA)


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

Kevin Lawson updated LUCENE-4947:
-

Attachment: MDAG-master.zip
LevenshteinAutomaton-master.zip

LevenshteinAutomaton-master.zip MD5 checksum: 081b417edbd7d2a562085e1c0dfb0a4c 

MDAG-master.zip MD5 checksum: 109e99dca700e02d1ad54306688472a5

 Java implementation (and improvement) of Levenshtein  associated lexicon 
 automata
 --

 Key: LUCENE-4947
 URL: https://issues.apache.org/jira/browse/LUCENE-4947
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0, 4.1, 4.2, 4.2.1
Reporter: Kevin Lawson
 Attachments: LevenshteinAutomaton-master.zip, MDAG-master.zip


 I was encouraged by Mike McCandless to open an issue concerning this after I 
 contacted him privately about it. Thanks Mike!
 I'd like to submit my Java implementation of the Levenshtein Automaton as a 
 homogenous replacement for the current heterogenous, multi-component 
 implementation in Lucene.
 Benefits of upgrading include 
 - Reduced code complexity
 - Better performance from components that were previously implemented in 
 Python
 - Support for on-the-fly dictionary-automaton manipulation (if you wish to 
 use my dictionary-automaton implementation)
 The code for all the components is well structured, easy to follow, and 
 extensively commented. It has also been fully tested for correct 
 functionality and performance.
 The levenshtein automaton implementation (along with the required MDAG 
 reference) can be found in my LevenshteinAutomaton Java library here: 
 https://github.com/klawson88/LevenshteinAutomaton.
 The minimalistic directed acyclic graph (MDAG) which the automaton code uses 
 to store and step through word sets can be found here: 
 https://github.com/klawson88/MDAG
 *Transpositions aren't currently implemented. I hope the comment filled, 
 editing-friendly code combined with the fact that the section in the Mihov 
 paper detailing transpositions is only 2 pages makes adding the functionality 
 trivial.
 *As a result of support for on-the-fly manipulation, the MDAG 
 (dictionary-automaton) creation process incurs a slight speed penalty. In 
 order to have the best of both worlds, i'd recommend the addition of a 
 constructor which only takes sorted input. The complete, easy to follow 
 pseudo-code for the simple procedure can be found in the first article I 
 linked under the references section in the MDAG repository)

--
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-4947) Java implementation (and improvement) of Levenshtein associated lexicon automata

2013-04-24 Thread Kevin Lawson (JIRA)


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

Kevin Lawson edited comment on LUCENE-4947 at 4/24/13 9:03 PM:
---

Hi all.

I've changed the license to the Apache License 2.0 and have modified all of the 
license notices. The checksums for the archives (which have been attached to 
this issue) are below:

LevenshteinAutomaton-master.zip MD5 checksum: 081b417edbd7d2a562085e1c0dfb0a4c 

MDAG-master.zip MD5 checksum: 109e99dca700e02d1ad54306688472a5

  was (Author: klawson88):
LevenshteinAutomaton-master.zip MD5 checksum: 
081b417edbd7d2a562085e1c0dfb0a4c 

MDAG-master.zip MD5 checksum: 109e99dca700e02d1ad54306688472a5
  
 Java implementation (and improvement) of Levenshtein  associated lexicon 
 automata
 --

 Key: LUCENE-4947
 URL: https://issues.apache.org/jira/browse/LUCENE-4947
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0, 4.1, 4.2, 4.2.1
Reporter: Kevin Lawson
 Attachments: LevenshteinAutomaton-master.zip, MDAG-master.zip


 I was encouraged by Mike McCandless to open an issue concerning this after I 
 contacted him privately about it. Thanks Mike!
 I'd like to submit my Java implementation of the Levenshtein Automaton as a 
 homogenous replacement for the current heterogenous, multi-component 
 implementation in Lucene.
 Benefits of upgrading include 
 - Reduced code complexity
 - Better performance from components that were previously implemented in 
 Python
 - Support for on-the-fly dictionary-automaton manipulation (if you wish to 
 use my dictionary-automaton implementation)
 The code for all the components is well structured, easy to follow, and 
 extensively commented. It has also been fully tested for correct 
 functionality and performance.
 The levenshtein automaton implementation (along with the required MDAG 
 reference) can be found in my LevenshteinAutomaton Java library here: 
 https://github.com/klawson88/LevenshteinAutomaton.
 The minimalistic directed acyclic graph (MDAG) which the automaton code uses 
 to store and step through word sets can be found here: 
 https://github.com/klawson88/MDAG
 *Transpositions aren't currently implemented. I hope the comment filled, 
 editing-friendly code combined with the fact that the section in the Mihov 
 paper detailing transpositions is only 2 pages makes adding the functionality 
 trivial.
 *As a result of support for on-the-fly manipulation, the MDAG 
 (dictionary-automaton) creation process incurs a slight speed penalty. In 
 order to have the best of both worlds, i'd recommend the addition of a 
 constructor which only takes sorted input. The complete, easy to follow 
 pseudo-code for the simple procedure can be found in the first article I 
 linked under the references section in the MDAG repository)

--
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-4749) Refactor the new solr.xml and core discovery code.


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

Mark Miller resolved SOLR-4749.
---

Resolution: Fixed

As far as a general attack on this, I'm done. I'll open specific JIRA issues 
for any further changes.

 Refactor the new solr.xml and core discovery code.
 --

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

 Attachments: SOLR-4749.patch


 I think we can clean up a variety of things in the latest code.

--
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-4758) Zk bootstrapping does not work with the new solr.xml format and core discovery by directory structure.


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

Mark Miller commented on SOLR-4758:
---

This will be fixed with SOLR-4757.

 Zk bootstrapping does not work with the new solr.xml format and core 
 discovery by directory structure.
 --

 Key: SOLR-4758
 URL: https://issues.apache.org/jira/browse/SOLR-4758
 Project: Solr
  Issue Type: Bug
  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

Re: [VOTE] Lucene Solr 4.3.0 RC3

2013-04-24 Thread Chris Hostetter


: 
http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC3-rev1470846/

+1 to releasing the artifacts with the following SHA1 signatures as 
Lucene/Solr 4.3.0...

3e1ec78f7b5bad2723dcf2f963d933758046afb9 *lucene-4.3.0-src.tgz
26843d53c86a9937d700f13f1d686adaca718244 *lucene-4.3.0.tgz
72b526a5aa21c7499954978a74e14ceac3a607ea *lucene-4.3.0.zip
9fd7abc7e478dbc5474658460da58ec360d6b1e4 *solr-4.3.0-src.tgz
5dca6da9f30830dc20163623b0a4f63749777f24 *solr-4.3.0.tgz
ba6c86209614e3fe8cddeb3193bb8a09299ea457 *solr-4.3.0.zip


FWIW: During my testing I did encounter one new bug: SOLR-4754, but since 
it has a workarround (and i have no idea yet what the underlying problem 
is to even try for a quick fix) I don't think it should block the release.


-Hoss

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

[jira] [Commented] (LUCENE-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Uwe Schindler commented on LUCENE-4953:
---

bq. Ie, today LuceneTestCase.maybeWrapReader never incRefs the incoming reader, 
but with the fix, ParallelCompositeReader now does ... so this leads to 
failures.

Passing false instead of true to the wrapper is wrong. The solution is to leave 
the construction as is, just in doClose() call notifyReaderClosedListeners() on 
all subreaders (which is unfortunately private). But this would still not help 
for tests, because maybeWrapReader tries to hide itsself from FieldCache (this 
is why it has FCInvisibleMultiReader). Tests always class the original reader 
never the wrapper, so although with this patch the whole thing does not work.

The test failure is very seldom because it only happens:
- if you wrap (rarely) with a ParallelMultiReader (more rarely)
- use FieldCache

The number of tests with FieldCache is very small, so it took more than 1 year 
to see the first failure :-)

In fact the problem for the actual test failure is maybeWrapReader in 
combination with FieldCache. maybeWrapReader should not use 
ParallelCompositeReader, if it knows that FieldCache will be used. 
Unfortunately this is not known before.

The problem with the readerClosedListener not called by ParallelCompositeReader 
(with closeSubReaders=true) is real, and only affects PCR, because it creates 
atomic readers with own fieldcache key. Because of that it should manually 
unregister them (and not close them)

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

 Key: LUCENE-4953
 URL: https://issues.apache.org/jira/browse/LUCENE-4953
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at

[jira] [Comment Edited] (LUCENE-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Uwe Schindler edited comment on LUCENE-4953 at 4/24/13 9:29 PM:


bq. Ie, today LuceneTestCase.maybeWrapReader never incRefs the incoming reader, 
but with the fix, ParallelCompositeReader now does ... so this leads to 
failures.

Passing false instead of true to the wrapper is wrong. The solution is to leave 
the construction as is, just in doClose() call notifyReaderClosedListeners() on 
all subreaders (which is unfortunately private). But this would still not help 
for tests, because maybeWrapReader tries to hide itsself from FieldCache (this 
is why it has FCInvisibleMultiReader). Tests almost always close the original 
reader and never the wrapper, so with this patch the whole thing does not work.

The test failure is very seldom because it only happens:
- if you wrap (rarely) with a ParallelMultiReader (more rarely)
- use FieldCache

The number of tests with FieldCache is very small, so it took more than 1 year 
to see the first failure :-)

In fact the problem for the actual test failure is maybeWrapReader in 
combination with FieldCache. maybeWrapReader should not use 
ParallelCompositeReader, if it knows that FieldCache will be used. 
Unfortunately this is not known before.

The problem with the readerClosedListener not called by ParallelCompositeReader 
(with closeSubReaders=true) is real, and only affects PCR, because it creates 
atomic readers with own fieldcache key. Because of that it should manually 
unregister them (and not close them)

  was (Author: thetaphi):
bq. Ie, today LuceneTestCase.maybeWrapReader never incRefs the incoming 
reader, but with the fix, ParallelCompositeReader now does ... so this leads to 
failures.

Passing false instead of true to the wrapper is wrong. The solution is to leave 
the construction as is, just in doClose() call notifyReaderClosedListeners() on 
all subreaders (which is unfortunately private). But this would still not help 
for tests, because maybeWrapReader tries to hide itsself from FieldCache (this 
is why it has FCInvisibleMultiReader). Tests always class the original reader 
never the wrapper, so although with this patch the whole thing does not work.

The test failure is very seldom because it only happens:
- if you wrap (rarely) with a ParallelMultiReader (more rarely)
- use FieldCache

The number of tests with FieldCache is very small, so it took more than 1 year 
to see the first failure :-)

In fact the problem for the actual test failure is maybeWrapReader in 
combination with FieldCache. maybeWrapReader should not use 
ParallelCompositeReader, if it knows that FieldCache will be used. 
Unfortunately this is not known before.

The problem with the readerClosedListener not called by ParallelCompositeReader 
(with closeSubReaders=true) is real, and only affects PCR, because it creates 
atomic readers with own fieldcache key. Because of that it should manually 
unregister them (and not close them)
  
 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

 Key: LUCENE-4953
 URL: https://issues.apache.org/jira/browse/LUCENE-4953
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at

[jira] [Commented] (SOLR-3781) when wiring Solr into a larger web application which controls the web context root,something can't work

2013-04-24 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-3781:


Since Servlet's can be mapped to multiple paths, i'm wondering if it would be 
cleaner and more straight forwarded just to add an optional path-prefix 
init-param to to LoadAdminUiServlet just like SolrDispatchFilter has, that 
people can configure in exactly the same way?

 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Uwe Schindler reassigned LUCENE-4953:
-

Assignee: Uwe Schindler

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

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

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at java.lang.Thread.run(Thread.java:722)
 Build Log:
 [...truncated 6904 lines...]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest
 [junit4:junit4]   2 *** BEGIN 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) ***
 [junit4:junit4]   2 VALUEMISMATCH: Multiple distinct value objects for 
 ParallelAtomicReader(_0(5.0):C3)+id
 [junit4:junit4]   2

[jira] [Updated] (SOLR-3781) when wiring Solr into a larger web application which controls the web context root,something can't work

2013-04-24 Thread Stefan Matheis (steffkes) (JIRA)


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

Stefan Matheis (steffkes) updated SOLR-3781:


  Component/s: web gui
Fix Version/s: 4.4
   5.0

 when wiring Solr into a larger web application which controls the web context 
 root,something can't work
 ---

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, web gui
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Fix For: 5.0, 4.4

 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-3781) Admin UI does not work when wiring Solr into a larger web application

2013-04-24 Thread Stefan Matheis (steffkes) (JIRA)


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

Stefan Matheis (steffkes) updated SOLR-3781:


Component/s: (was: SolrCloud)
Summary: Admin UI does not work when wiring Solr into a larger web 
application  (was: when wiring Solr into a larger web application which 
controls the web context root,something can't work)

 Admin UI does not work when wiring Solr into a larger web application
 -

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Fix For: 5.0, 4.4

 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-4951) DrillSidewaysScorer should use Scorer.cost instead of its own heuristic


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

Commit Tag Bot commented on LUCENE-4951:


[trunk commit] mikemccand
http://svn.apache.org/viewvc?view=revisionrevision=1471705

LUCENE-4951: DrillSideways now uses Scorer.cost() to decide which scorer impl 
to use

 DrillSidewaysScorer should use Scorer.cost instead of its own heuristic
 ---

 Key: LUCENE-4951
 URL: https://issues.apache.org/jira/browse/LUCENE-4951
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4951.patch


 Today it does the first docID trick to guess the cost of the
 baseQuery, which is silly now that we have cost API.

--
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-4951) DrillSidewaysScorer should use Scorer.cost instead of its own heuristic


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

Commit Tag Bot commented on LUCENE-4951:


[branch_4x commit] mikemccand
http://svn.apache.org/viewvc?view=revisionrevision=1471707

LUCENE-4951: DrillSideways now uses Scorer.cost() to decide which scorer impl 
to use

 DrillSidewaysScorer should use Scorer.cost instead of its own heuristic
 ---

 Key: LUCENE-4951
 URL: https://issues.apache.org/jira/browse/LUCENE-4951
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4951.patch


 Today it does the first docID trick to guess the cost of the
 baseQuery, which is silly now that we have cost API.

--
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-4951) DrillSidewaysScorer should use Scorer.cost instead of its own heuristic


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

Michael McCandless resolved LUCENE-4951.


Resolution: Fixed

 DrillSidewaysScorer should use Scorer.cost instead of its own heuristic
 ---

 Key: LUCENE-4951
 URL: https://issues.apache.org/jira/browse/LUCENE-4951
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4951.patch


 Today it does the first docID trick to guess the cost of the
 baseQuery, which is silly now that we have cost API.

--
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-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Michael McCandless commented on LUCENE-4953:


It's ... spooky how PCR makes new (private) readers but never closes them :)  
But it seems hard to fix that correctly because of how LTC wraps the readers in 
newSearcher.

+1 to just invoke the readerClosedListeners directly from PCR.doClose.  It's a 
little un-clean duplicating this code but I don't see how else to fix it ...

bq. The number of tests with FieldCache is very small, so it took more than 1 
year to see the first failure 

It's even more restrictive: the test must also create FieldCache insanity.  
This particular test always does so ... but because we purge the insanity on 
close (except in this case) the insanity never causes a test failure.

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

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

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at

[jira] [Commented] (LUCENE-4952) DrillSideways should expose scoreSubDocsAtOnce control

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

Commit Tag Bot commented on LUCENE-4952:

[trunk commit] mikemccand
http://svn.apache.org/viewvc?view=revisionrevision=1471732

LUCENE-4952: add method to force DrillSideways to keep all sub-scorers on the
doc being collected

DrillSideways should expose scoreSubDocsAtOnce control

Key: LUCENE-4952
URL: https://issues.apache.org/jira/browse/LUCENE-4952
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.0, 4.4

Attachments: LUCENE-4952.patch

I hit this when running a ToParentBlockJoinCollector/Query under
DrillSideways ... the problem is ToParentBlockJoinCollector.collect
expects that all sub-scorers are positioned on the docID being
collected, but DrillSideways sometimes scores with a in-order
BooleanScorer-like scorer that advances each sub-scorer in chunks
... this breaks ToParentBlockJoinCollector.
This is the same issue as LUCENE-2686, where apps that want to peek at
the sub-scorers from their collector need those sub-scorers to all be
on the current docID being collected...
One way to fix this would be to switch based on
Collector.acceptsDocsOutOfOrder() ... but that's really a hack ... it
only works for BooleanQuery because BooleanScorer is an out-of-order
scorer (well and because we fixed all BS2s to keep sub-scorers
positioned on the doc being collected in LUCENE-3505).
But if for example we added MUST clauses back into BooleanScorer
(which I think we should!) then it could easily score those queries
in-order. Really we need another boolean (scoreSubDocsAtOnce or
something) to Weight.scorer... but that's a big change...
I think for this issue I'll just add an expert protected method to
DrillSideways that returns this boolean, and an app could subclass to
override. Apps that know they are using queries/collectors like
ToParentBlockJoinQuery/Collector must subclass and override
... DrillSideways already has other expert methods that you subclass
override.

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

[jira] [Commented] (LUCENE-4952) DrillSideways should expose scoreSubDocsAtOnce control

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

Commit Tag Bot commented on LUCENE-4952:

[trunk commit] mikemccand
http://svn.apache.org/viewvc?view=revisionrevision=1471733

LUCENE-4952: put CHANGES entry in the right place

DrillSideways should expose scoreSubDocsAtOnce control

Key: LUCENE-4952
URL: https://issues.apache.org/jira/browse/LUCENE-4952
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.0, 4.4

Attachments: LUCENE-4952.patch

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

[jira] [Commented] (LUCENE-4952) DrillSideways should expose scoreSubDocsAtOnce control

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

Commit Tag Bot commented on LUCENE-4952:

[branch_4x commit] mikemccand
http://svn.apache.org/viewvc?view=revisionrevision=1471735

LUCENE-4952: add method to force DrillSideways to keep all sub-scorers on the
doc being collected

DrillSideways should expose scoreSubDocsAtOnce control

Key: LUCENE-4952
URL: https://issues.apache.org/jira/browse/LUCENE-4952
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.0, 4.4

Attachments: LUCENE-4952.patch

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

[jira] [Resolved] (LUCENE-4952) DrillSideways should expose scoreSubDocsAtOnce control

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

Michael McCandless resolved LUCENE-4952.

Resolution: Fixed

DrillSideways should expose scoreSubDocsAtOnce control

Key: LUCENE-4952
URL: https://issues.apache.org/jira/browse/LUCENE-4952
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.0, 4.4

Attachments: LUCENE-4952.patch

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

[jira] [Commented] (LUCENE-4951) DrillSidewaysScorer should use Scorer.cost instead of its own heuristic


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

Commit Tag Bot commented on LUCENE-4951:


[trunk commit] mikemccand
http://svn.apache.org/viewvc?view=revisionrevision=1471738

LUCENE-4951: cutover another freq - cost

 DrillSidewaysScorer should use Scorer.cost instead of its own heuristic
 ---

 Key: LUCENE-4951
 URL: https://issues.apache.org/jira/browse/LUCENE-4951
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4951.patch


 Today it does the first docID trick to guess the cost of the
 baseQuery, which is silly now that we have cost API.

--
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-4951) DrillSidewaysScorer should use Scorer.cost instead of its own heuristic


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

Commit Tag Bot commented on LUCENE-4951:


[branch_4x commit] mikemccand
http://svn.apache.org/viewvc?view=revisionrevision=1471741

LUCENE-4951: cutover another freq - cost

 DrillSidewaysScorer should use Scorer.cost instead of its own heuristic
 ---

 Key: LUCENE-4951
 URL: https://issues.apache.org/jira/browse/LUCENE-4951
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.4

 Attachments: LUCENE-4951.patch


 Today it does the first docID trick to guess the cost of the
 baseQuery, which is silly now that we have cost API.

--
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-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Uwe Schindler updated LUCENE-4953:
--

Attachment: LUCENE-4953.patch

Patch that notifies the readerClosedListeners of all childs instead of closing 
them completely. This is now correct, but very crazy.

For this patch I made the notify method package protected, not sure if we 
should make it protected for other/similar readers?

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

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

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at java.lang.Thread.run(Thread.java:722)
 Build Log:
 [...truncated 6904 lines...]
 [junit4:junit4] Suite:

[jira] [Commented] (LUCENE-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Uwe Schindler commented on LUCENE-4953:
---

Of course the patch does not fix the test failures occuring because test never 
close the wrapper, but the original reader. This is a bug in maybeWrapReader 
(because maybeWrapReader should be side-effect free, but the side-effect here 
is that an entry in the FieldCache may be created by a private atomicreader 
instance which is just a wrapper and never closed).

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

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

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at

Solr - are there tests for CoreAdmin functions, specifically SWAP?

2013-04-24 Thread Shawn Heisey

I couldn't find any evidence of a test in Solr for the CoreAdmin SWAP 
functionality.  Does one exist that I missed?  If not, I'll file an 
issue for testing of all CoreAdmin actions.


When I rebuild my entire index, I do a number of SWAP actions, one for 
each shard.  It works well for me up through 4.2.1, but with solr.xml 
changing format and moving to autodiscovery, the mechanism for swaps and 
renames will have to change.  Before, these actions would result in 
changes to the core definitions in solr.xml, but now the code must 
change core.properties in the affected cores.


Thanks,
Shawn

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

[jira] [Commented] (LUCENE-4953) readerClosedListener is not invoked for ParallelCompositeReader's leaves


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

Uwe Schindler commented on LUCENE-4953:
---

Another possibility to make the readerClosed notification working, would be to 
have on PCR and PAR a 3rd mode (pkg-private ctor) where doClose() is a noop. In 
that case, the PCR could call close() on all of its subReaders, but the 
refCount or the childs are not closed unless otherwise specified in the ctor. 
And we dont need to make the private notify method visible to other classes.

I will provide a patch tomorrow, this seems to be the cleanest solution for the 
readerClosedListener bug (but not the test failures).

 readerClosedListener is not invoked for ParallelCompositeReader's leaves
 

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

 Attachments: LUCENE-4953.patch, LUCENE-4953.patch, LUCENE-4953.patch


 There was a test failure last night:
 {noformat}
 1 tests failed.
 REGRESSION:  
 org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest.testBasic
 Error Message:
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 Stack Trace:
 java.lang.AssertionError: 
 testBasic(org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest): 
 Insane FieldCache usage(s) found expected:0 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([1F9C2A2AD23A8E02:B466373F0DE6082C]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at 
 org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:592)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:55)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at

[jira] [Created] (SOLR-4759) Cleanup Velocity Templates

2013-04-24 Thread Mark Bennett (JIRA)

Mark Bennett created SOLR-4759:
--

 Summary: Cleanup Velocity Templates
 Key: SOLR-4759
 URL: https://issues.apache.org/jira/browse/SOLR-4759
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
Reporter: Mark Bennett


Cleanup to Velocity templates shipped under 
solr/example/solr/collection1/conf/velocity

* Add README.txt file with complete file list
* Add comments to all files
* Add indenting where feasible, fixed indenting in other places.  I don't 
believe I've broken anything that required precise indenting.
* Make file naming consistent.  We had this_that, thisThat and this-that
  Changed all to this_that, though also considered this-that.
* Modularize some files
* Included a hit_plain.vm example, though not active by default.
* Rewrote city/lon/lat selector to work from a hash, though doesn't change the 
behavior.
* CSS changes, primarily to make top tabs actually look like Tabs (primitive 
CSS, but at least conveys the idea)

As far as I know this doesn't change any behavior of the system, nor does it 
fix any existing bugs.  Although I might do bug fixing in a later patch, I 
wanted to keep this as a pure code readability 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] [Updated] (SOLR-4759) Cleanup Velocity Templates

2013-04-24 Thread Mark Bennett (JIRA)

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

Mark Bennett updated SOLR-4759:
---

Attachment: SOLR-4759.patch

Patch against TRUNK

[jira] [Commented] (SOLR-3781) Admin UI does not work when wiring Solr into a larger web application

2013-04-24 Thread Alin Simionoiu (JIRA)


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

Alin Simionoiu commented on SOLR-3781:
--

not enough. as you can see from the sample web.xml you have to add that path 
all over the place, not just for LoadAdminUIServlet.

 Admin UI does not work when wiring Solr into a larger web application
 -

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Fix For: 5.0, 4.4

 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-3781) Admin UI does not work when wiring Solr into a larger web application

2013-04-24 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-3781:


Alin: yes, if you want all those various servlets to work, then each needs to 
be configured with the path -- i don't think anyone has questioned that.  the 
point is about how/where/when LoadAdminUiServlet knows about the path to use 
when dealing with the static resources.

my point is that instead of trying to guess where to find those resources 
based on the servlet path of the request, we should just make it an explicit 
configuration, the same way it's explicit in SolrDispatchFilter -- that way 
people can use anything they want, even if they choose to bind 
LoadAdminUiServlet to multiple paths.

 Admin UI does not work when wiring Solr into a larger web application
 -

 Key: SOLR-3781
 URL: https://issues.apache.org/jira/browse/SOLR-3781
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0-BETA
 Environment: win7 jetty-distribution-7.6.5.v20120716
 startup param:
 -Djetty.port=8084 -DzkRun -Dbootstrap_conf=true
Reporter: shenjc
Priority: Minor
  Labels: patch
 Fix For: 5.0, 4.4

 Attachments: LoadAdminUiServlet.patch, 
 LoadAdminUiServlet_take2.patch, web.xml

   Original Estimate: 24h
  Remaining Estimate: 24h

 if i am wiring Solr into a larger web application which controls the web 
 context root, you will probably want to mount Solr under a path prefix 
 (app.war with /app/solr mounted into it, for example).
  For example:
 RootApp.war /
 myApp.war---/myApp
 prefixPath---xxx
 jsdir--js
 js filemain.js
 admin file-admin.html
 org.apache.solr.servlet.LoadAdminUiServlet
 line:49  InputStream in = 
 getServletContext().getResourceAsStream(/admin.html);
 can't find admin/html because it's in the prefixPath directory
 org.apache.solr.cloud.ZkController
 line:149-150
 this.nodeName = this.hostName + ':' + this.localHostPort + '_' + 
 this.localHostContext;
 this.baseURL = this.localHost + : + this.localHostPort + / + 
 this.localHostContext;
 it can't match this condition
 baseURL need to be http://xx:xx/myApp/myPrefixPath 
 eg. http://xx:xx/myApp/xxx

--
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-3781) Admin UI does not work when wiring Solr into a larger web application