[jira] [Updated] (GEODE-2997) New flow: putAll/getAll

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2997:

Description: 
Create proto message definitions and op handler for putAll/getAll messages.

Client should be able to complete putAll/getAll of primitives and JSON with 
response.

  was:
Create proto message definitions and op handler for get/getAll messages.

Client should be able to complete get/getAll of primitives and JSON with 
response.

Summary: New flow: putAll/getAll  (was: New flow: get/getAll)

> New flow: putAll/getAll
> ---
>
> Key: GEODE-2997
> URL: https://issues.apache.org/jira/browse/GEODE-2997
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Create proto message definitions and op handler for putAll/getAll messages.
> Client should be able to complete putAll/getAll of primitives and JSON with 
> response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2996) New flow: put/get

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2996:

Description: 
Create proto message definitions and op handler for put/get messages.

Client should be able to complete put/get of primitives and JSON with response.

  was:
Create proto message definitions and op handler for put/putAll messages.

Client should be able to complete put/putAll of primitives and JSON with 
response.

Summary: New flow: put/get  (was: New flow: put/putAll)

> New flow: put/get
> -
>
> Key: GEODE-2996
> URL: https://issues.apache.org/jira/browse/GEODE-2996
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Create proto message definitions and op handler for put/get messages.
> Client should be able to complete put/get of primitives and JSON with 
> response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2997) New flow: get/getAll

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2997:

Description: 
Create proto message definitions and op handler for get/getAll messages.

Client should be able to complete get/getAll of primitives and JSON with 
response.

  was:
Create proto message definitions and op handler for putAll/getAll messages.

Client should be able to complete putAll/getAll of primitives and JSON with 
response.

Summary: New flow: get/getAll  (was: New flow: putAll/getAll)

> New flow: get/getAll
> 
>
> Key: GEODE-2997
> URL: https://issues.apache.org/jira/browse/GEODE-2997
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Create proto message definitions and op handler for get/getAll messages.
> Client should be able to complete get/getAll of primitives and JSON with 
> response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2999) New flow: replace/put if absent

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2999:
---

 Summary: New flow: replace/put if absent
 Key: GEODE-2999
 URL: https://issues.apache.org/jira/browse/GEODE-2999
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create proto message definitions and op handler for replace/put if absent 
messages.

Client should be able to complete replace/put if absent of primitives and JSON 
with response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2996) New flow: put/putAll

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2996:

Description: 
Create proto message definitions and op handler for put/putAll messages.

Client should be able to complete put/putAll of primitives and JSON with 
response.

  was:
Create proto message definitions and op handler for put/get messages.

Client should be able to complete put/get of primitives and JSON with response.

Summary: New flow: put/putAll  (was: New flow: put/get)

> New flow: put/putAll
> 
>
> Key: GEODE-2996
> URL: https://issues.apache.org/jira/browse/GEODE-2996
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Brian Baynes
>
> Create proto message definitions and op handler for put/putAll messages.
> Client should be able to complete put/putAll of primitives and JSON with 
> response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2998) New flow: remove/removeAll

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2998:
---

 Summary: New flow: remove/removeAll
 Key: GEODE-2998
 URL: https://issues.apache.org/jira/browse/GEODE-2998
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create proto message definitions and op handler for remove/removeAll messages.

Client should be able to complete remove/removeAll with response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2997) New flow: putAll/getAll

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2997:
---

 Summary: New flow: putAll/getAll
 Key: GEODE-2997
 URL: https://issues.apache.org/jira/browse/GEODE-2997
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create proto message definitions and op handler for putAll/getAll messages.

Client should be able to complete putAll/getAll of primitives and JSON with 
response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2996) New flow: put/get

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2996:
---

 Summary: New flow: put/get
 Key: GEODE-2996
 URL: https://issues.apache.org/jira/browse/GEODE-2996
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create proto message definitions and op handler for put/get messages.

Client should be able to complete put/get of primitives and JSON with response.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2995) Introduce new protocol flow into core

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2995:
---

 Summary: Introduce new protocol flow into core
 Key: GEODE-2995
 URL: https://issues.apache.org/jira/browse/GEODE-2995
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create new protocol flow in core to handle incoming client messages, 
serialize/de-serialize primitives and JSON, construct/de-construct messages, 
and complete operations with response.

New protocol flow should handle put/get messages with response, covering 
primitives and JSON.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2939) Initiate bucket event tracker and get GII from different source could lead to bucket copies inconsistence

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-2939.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> Initiate bucket event tracker and get GII from different source could lead to 
> bucket copies inconsistence
> -
>
> Key: GEODE-2939
> URL: https://issues.apache.org/jira/browse/GEODE-2939
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> When a bucket region is created, it send CreateRegionMessage to all nodes 
> hosting the bucket data. It initiates its event tracker from the first one 
> replied. 
> In one case, it copies event tracker states from the node with primary 
> bucket, which is processing putAll operation and already applied a few entry 
> operations (so the newer seqNo is recorded for the thread performing the 
> putAll). 
> However, it gets initial image from another node -- which does not have the 
> entry operations yet (as putAll op is not yet being distributed to secondary 
> yet.)
> The newly created region would receive all the putAll operations from the 
> primary when the primary distributes the putAll operations to secondary 
> copies. In the node with newly created region, some of the events would not 
> be applied due to hasSeenEvent method call (up to initiated last seqNo for 
> the said thread). This leads to bucket inconsistence among the redundant 
> copies.
> Please note this issue would not occur if there is only one redundant copy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2939) Initiate bucket event tracker and get GII from different source could lead to bucket copies inconsistence

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025585#comment-16025585
 ] 

ASF subversion and git services commented on GEODE-2939:


Commit 56f976c89fabed58a086a845593efc2ef6e75114 in geode's branch 
refs/heads/develop from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=56f976c ]

GEODE-2939: Make sure bucket region initiate event tracker from the image 
provider.

Save all event states from remote processes.
Initiate event tracker from the image provider only.


> Initiate bucket event tracker and get GII from different source could lead to 
> bucket copies inconsistence
> -
>
> Key: GEODE-2939
> URL: https://issues.apache.org/jira/browse/GEODE-2939
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>  Labels: storage_2
>
> When a bucket region is created, it send CreateRegionMessage to all nodes 
> hosting the bucket data. It initiates its event tracker from the first one 
> replied. 
> In one case, it copies event tracker states from the node with primary 
> bucket, which is processing putAll operation and already applied a few entry 
> operations (so the newer seqNo is recorded for the thread performing the 
> putAll). 
> However, it gets initial image from another node -- which does not have the 
> entry operations yet (as putAll op is not yet being distributed to secondary 
> yet.)
> The newly created region would receive all the putAll operations from the 
> primary when the primary distributes the putAll operations to secondary 
> copies. In the node with newly created region, some of the events would not 
> be applied due to hasSeenEvent method call (up to initiated last seqNo for 
> the said thread). This leads to bucket inconsistence among the redundant 
> copies.
> Please note this issue would not occur if there is only one redundant copy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2957) null used as a default parameter when specifying analyzers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025572#comment-16025572
 ] 

ASF GitHub Bot commented on GEODE-2957:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/537


> null used as a default parameter when specifying analyzers
> --
>
> Key: GEODE-2957
> URL: https://issues.apache.org/jira/browse/GEODE-2957
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> null seems to be the way to specify using the default 
> StandardKeywordAnalyzer. This can be used when specifying a long list of 
> field/analyzers.  
> So the line may look like 
> --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer}
>  We should probably change that to default or some other keyword.  null seems 
> a bit confusing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #537: GEODE-2957: Added DEFAULT as a standardAnalyzer key...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/537


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2957) null used as a default parameter when specifying analyzers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025571#comment-16025571
 ] 

ASF subversion and git services commented on GEODE-2957:


Commit 29ea88a23ef0feb29e8d7684c4061ac54dc66874 in geode's branch 
refs/heads/develop from [~DivineEnder]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=29ea88a ]

GEODE-2957: Lucene create index DEFAULT keyword added for standardAnalyzer

This closes #537


> null used as a default parameter when specifying analyzers
> --
>
> Key: GEODE-2957
> URL: https://issues.apache.org/jira/browse/GEODE-2957
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> null seems to be the way to specify using the default 
> StandardKeywordAnalyzer. This can be used when specifying a long list of 
> field/analyzers.  
> So the line may look like 
> --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer}
>  We should probably change that to default or some other keyword.  null seems 
> a bit confusing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2985) Doc task: making/using backups when there are indexes

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-2985.

Resolution: Invalid

Ticket has incorrect info.  Will open a new ticket with correct info.

> Doc task: making/using backups when there are indexes
> -
>
> Key: GEODE-2985
> URL: https://issues.apache.org/jira/browse/GEODE-2985
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> We should document that making a backup or using a backup to restore a system 
> when that system also has/had indexes can be problematic.
> When taking a backup on a system that has an index, if there are region 
> operations in progress, the asynchronous nature of propagating the results of 
> the operations to an index means that the index content may be inconsistent 
> with the region content.  If the backup were later used to restore a system, 
> the inconsistency will be introduced back into the system.
> The fix for this is to make sure that the system is quiescent with respect to 
> region operations when a backup is taken.
> In addition, the restoration procedure should rebuild indexes.
> This issue exists for both regular (OQL) indexes and for Lucene indexes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59404: GEODE-2939: make sure event tracker is initiated from the GII provider

[Darrel Schneider]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59404/#review176146
---




geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
Line 203 (original), 207 (patched)


You need this map to be thread safe because concurrent puts can happen as 
you process multiple replies concurrently.

You can wrap it in either Collections.synchronizedMap or you can make it a 
ConcurrentHashMap.

Also you could make this line less verbose by just using "<>" on the new 
side (I think).


- Darrel Schneider


On May 24, 2017, 5:51 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59404/
> ---
> 
> (Updated May 24, 2017, 5:51 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
> Gallinat.
> 
> 
> Bugs: GEODE-2939
> https://issues.apache.org/jira/browse/GEODE-2939
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Event tracker initilization for bucket region is delayed until after GII, and 
> will be initialized from the GII provider.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
> 886d678 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CacheDistributionAdvisee.java
>  e4a7957 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
>  c1d1e77 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
>  485835b 
>   geode-core/src/main/java/org/apache/geode/internal/cache/EventTracker.java 
> 2c86aed 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/InitialImageOperation.java
>  fb5f0cf 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/EventTrackerDUnitTest.java
>  3faf41f 
> 
> 
> Diff: https://reviews.apache.org/r/59404/diff/4/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

[jira] [Commented] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025541#comment-16025541
 ] 

ASF GitHub Bot commented on GEODE-2950:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/540


> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025540#comment-16025540
 ] 

ASF subversion and git services commented on GEODE-2950:


Commit 5ab4a69378c697fdf050048165e2945a4b028eb7 in geode's branch 
refs/heads/develop from [~DivineEnder]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5ab4a69 ]

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.

This closes #540


> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #540: GEODE-2950: Updated error messages

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/540


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #539: GEODE-2818: add alias to any command's options that involv...

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/539
  
Thanks for your contribution, Emily!  It looks like this branch will need 
to be rebased onto the latest develop to apply cleanly.  Would you mind 
updating the PR with a rebased version of these changes?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2818) add alias to any command's options that involves "group", "member", "jar"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025538#comment-16025538
 ] 

ASF GitHub Bot commented on GEODE-2818:
---

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/539
  
Thanks for your contribution, Emily!  It looks like this branch will need 
to be rebased onto the latest develop to apply cleanly.  Would you mind 
updating the PR with a rebased version of these changes?


> add alias to any command's options that involves "group", "member", "jar"
> -
>
> Key: GEODE-2818
> URL: https://issues.apache.org/jira/browse/GEODE-2818
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, gfsh
>Reporter: Jinmei Liao
>
> Or anything that would have confusion about if we are going to use singular 
> or plural at all.
> 1) add alias for those options
> 2) make sure it parameter type is an array type, some method only accepts a 
> string and split it inside the command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59542: GEODE-2974: rename ResultBuilder methods: GemFire -> Geode

[Darrel Schneider]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59542/#review176144
---



- Darrel Schneider


On May 24, 2017, 3:20 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59542/
> ---
> 
> (Updated May 24, 2017, 3:20 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Change GemFire to Geode in method names and message string
> 
> This is change to simply correct the Gfsh command error strings where 
> "GemFire" appears. With additional work on Gfsh command error handling 
> pending (see GEODE-2984), no attempt has been made within the scope of this 
> issue to reorganize or otherwise improve Gfsh command error messages.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ClientCommands.java
>  18940fc0c6c0f36a7dd5cab5723d426d80df3cb9 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  6d3f50ff2bcdf9d0450dd40a8defb83c2f2f6e04 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  b8ebc4917d88ce089ec2a19d606e004c1e5c6b33 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  a38e54504e949905f222d9891f624e373219364b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  4018beb8dfbd4bb639aec559991452226f15c908 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  4232d91edc9a74db144d49542d79f7cfd9f4a98b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DurableClientCommands.java
>  bcbfcf0ca72876dbfb3d41613159aa051726870e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
>  ea101826493bfbc9211b4c673c596d7514a7f431 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  b824bc915d453defe1c665eb7811a782f2c72fdf 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptor.java
>  5f2184889d28f441eb639d7ddf4ec2b7abfa293b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  2007e4af516274ac815cc3b06b9928f1aaed313f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  a4ba64c608f184fb130eb5ca3a05822f6cf82818 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  74acfd6e03613ac4d0c62fcdd4ea859d1c74d2f2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MemberCommands.java
>  415dd691cc6ed14bc67626881eecf65d5e446c99 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
>  0d714f4c295e2aded0c0fd28bbf4f72ffcdd14a7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
>  0ce8ec272eee9f07a05aa0ac478e136163ee41e6 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  6208adb63cc29f213c035849c78c3809f61b3f16 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/RegionCommands.java
>  561d4b8514c5b4500bf870e0b9d0ef3bcdbaf40d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
>  ad344ff598db5474846d1b6b334d377e01c5fbd7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  feeb3533e84fafbf22e5f9283690fe2ef0edf27e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
>  fe88fc98d397fa748f8f54b900b1511eb114c0b6 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/ResultBuilder.java
>  6332540aa4ff6d210ed7f3ba167057de9a0a5023 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.java
>  2b39bedd1bcceef50e3f4933e17581048142a29b 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  5e17f6e55e6726f22cc39ddaba1ec608ca5cab9d 
> 
> 
> Diff: https://reviews.apache.org/r/59542/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin is running
> 
> 
> Thanks,
> 

[jira] [Assigned] (GEODE-2993) Lucene query inconsistency detected after user region event fired during cache close

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey reassigned GEODE-2993:
--

Assignee: Shelley Lynn Hughes-Godfrey

> Lucene query inconsistency detected after user region event fired during 
> cache close
> 
>
> Key: GEODE-2993
> URL: https://issues.apache.org/jira/browse/GEODE-2993
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> Lucene indexes may not be updated when the member hosting the primary is 
> undergoing cache close while the CacheListener is being fired (resulting in 
> data inconsistency between user region and lucene query).
> AbstractGatwaySender.distribute() simply catches and logs 
> CacheClosedExceptions which causes those events to be lost.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #565 was SUCCESSFUL (with 1848 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #565 was successful.
---
Scheduled
1850 tests in total.

https://build.spring.io/browse/SGF-NAG-565/





--
This message is automatically generated by Atlassian Bamboo

[jira] [Commented] (GEODE-2993) Lucene query inconsistency detected after user region event fired during cache close

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025508#comment-16025508
 ] 

ASF subversion and git services commented on GEODE-2993:


Commit 0fe0a1061065f07d4b734d7055f56ad1635f1a2a in geode's branch 
refs/heads/develop from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0fe0a10 ]

GEODE-2993: Rethrow CacheClosedException from AbstractGatewaySender.distribute()

- rethrow CacheClosedException
- Add test for cache close while enqueuing event in AEQ.
- Add cleanup of disk dirs created by test.


> Lucene query inconsistency detected after user region event fired during 
> cache close
> 
>
> Key: GEODE-2993
> URL: https://issues.apache.org/jira/browse/GEODE-2993
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> Lucene indexes may not be updated when the member hosting the primary is 
> undergoing cache close while the CacheListener is being fired (resulting in 
> data inconsistency between user region and lucene query).
> AbstractGatwaySender.distribute() simply catches and logs 
> CacheClosedExceptions which causes those events to be lost.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Proposal: Remove the "user-command-packages" system property

[Darrel Schneider]

The only concern I would have is that this might cause gfsh to load other
things that implement the spring CommandMarker that have nothing to do with
gfsh simply because they are in one of the jars. I really don't know how
likely that would be to happen but it seems more likely since the scan
happens on both sides.

Since the default for this property is the empty string you could just
change the default behavior to scan everything (instead of nothing) but
still allow them to limit where it scans be specifying a non-default value.


On Thu, May 25, 2017 at 2:30 PM, Jinmei Liao  wrote:

> both sides.
>
> On Thu, May 25, 2017 at 2:16 PM, Darrel Schneider 
> wrote:
>
> > What JVM does this scanning? Is it just the top-level shell JVM or does
> it
> > happen on the jmx-manager side?
> >
> > On Thu, May 25, 2017 at 1:01 PM, Jared Stewart 
> > wrote:
> >
> > > It sounds like we're on the same page.
> > >
> > > The current behavior requires two pieces from a user who wants to add
> > > commands:
> > > 1) implement CommandMarker
> > > 2) Add a system property pointing to the package of your class, or
> > provide
> > > a META-INF.services file pointing to your class
> > >
> > > The proposed behavior is to drop 2) and rely on 1) alone.
> > >
> > > On May 25, 2017 12:55 PM, "Udo Kohlmeyer" 
> wrote:
> > >
> > > What I meant was, given our hammer of choice for GFSH is Spring Shell,
> > all
> > > command definitions should be of type CommandMarker.
> > >
> > > Not sure how it loads the correct CommandMarker classes (for different
> > > commands). But my gut feel is, have single way of doing something...
> KISS
> > >
> > >
> > >
> > > On 5/25/17 12:22, Jared Stewart wrote:
> > >
> > > > Can you clarify - I'm proposing we use *implements CommandMarker*
> alone
> > > as
> > > > the way to specify commands. What do we gain be *also* requiring a
> > > > META-INF.services file?
> > > >
> > > > On May 25, 2017 12:18 PM, "Udo Kohlmeyer" 
> > wrote:
> > > >
> > > > imo, I think that GFSH is Spring Shell, it should really only be
> > commands
> > > > that are registered inside of META-INF.services .. aka implements
> > > > CommandMarker.
> > > >
> > > > This way we has standard simple way to specify commands.
> > > >
> > > > --Udo
> > > >
> > > >
> > > >
> > > > On 5/25/17 11:52, Jared Stewart wrote:
> > > >
> > > > I would like to propose that we eliminate the “user-command-packages”
> > > >> system property, in favor of scanning the entire classpath to find
> > > >> commands.
> > > >>
> > > >> To give more detail, Geode currently supports three ways to load
> GFSH
> > > >> commands:
> > > >> Scan the classpath for commands in "org.apache.geode.management.i
> > > >> nternal.cli.commands”
> > > >> Scan the classpath for commands in a package specified by a user via
> > the
> > > >> “user-command-packages” system property.
> > > >> Scan the classpath for commands registered in files inside
> > > >> META-INF.services (e.g. "geode-core/src/test/resources
> > > >> /META-INF/services/org.springframework.shell.core.CommandMarker”)
> > > >>
> > > >> We have some bespoke code responsible for scanning the classpath
> > > >> (ClasspathScanLoadHelper) that I am in the process of replacing with
> > > >> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will
> no
> > > >> longer need to eagerly load all of the classes in the target
> package,
> > I
> > > >> don’t see any reason why a user should need to specify a
> > > >> “user-command-package” property or a “META-INF/services” file.
> > Instead,
> > > >> we
> > > >> should just scan the whole classpath and register any commands that
> we
> > > >> find.
> > > >>
> > > >> Thoughts?
> > > >>
> > > >>
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

[jira] [Created] (GEODE-2993) Lucene query inconsistency detected after user region event fired during cache close

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2993:
--

 Summary: Lucene query inconsistency detected after user region 
event fired during cache close
 Key: GEODE-2993
 URL: https://issues.apache.org/jira/browse/GEODE-2993
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


Lucene indexes may not be updated when the member hosting the primary is 
undergoing cache close while the CacheListener is being fired (resulting in 
data inconsistency between user region and lucene query).

AbstractGatwaySender.distribute() simply catches and logs CacheClosedExceptions 
which causes those events to be lost.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2993) Lucene query inconsistency detected after user region event fired during cache close

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2993:
---
Affects Version/s: 1.2.0

> Lucene query inconsistency detected after user region event fired during 
> cache close
> 
>
> Key: GEODE-2993
> URL: https://issues.apache.org/jira/browse/GEODE-2993
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> Lucene indexes may not be updated when the member hosting the primary is 
> undergoing cache close while the CacheListener is being fired (resulting in 
> data inconsistency between user region and lucene query).
> AbstractGatwaySender.distribute() simply catches and logs 
> CacheClosedExceptions which causes those events to be lost.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025481#comment-16025481
 ] 

ASF GitHub Bot commented on GEODE-2950:
---

GitHub user DivineEnder opened a pull request:

https://github.com/apache/geode/pull/540

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2950

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/540.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #540


commit 382f3e672964c76c3854f33c3b628c5a0234eb66
Author: David Anuta 
Date:   2017-05-25T22:18:40Z

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.




> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025482#comment-16025482
 ] 

ASF GitHub Bot commented on GEODE-2950:
---

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/540
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #540: GEODE-2950: Updated error messages

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/540
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #540: GEODE-2950: Updated error messages

[DivineEnder]

GitHub user DivineEnder opened a pull request:

https://github.com/apache/geode/pull/540

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2950

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/540.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #540


commit 382f3e672964c76c3854f33c3b628c5a0234eb66
Author: David Anuta 
Date:   2017-05-25T22:18:40Z

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025462#comment-16025462
 ] 

ASF GitHub Bot commented on GEODE-2977:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/536


> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #536: GEODE-2977: make group/name option values consisten...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/536


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025460#comment-16025460
 ] 

ASF subversion and git services commented on GEODE-2977:


Commit c1ab3ffecb0c0a435fab64e94a97c2efc28ab085 in geode's branch 
refs/heads/develop from YehEmily
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c1ab3ff ]

GEODE-2977: make group/name option values consistent

* this closes #536


> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2992) Update openssl download URI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025442#comment-16025442
 ] 

ASF subversion and git services commented on GEODE-2992:


Commit 5ee98401edf8e7861be1bf5af5b668fe356c0b37 in geode-native's branch 
refs/heads/develop from [~eburghardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=5ee9840 ]

GEODE-2992: updated URI for openssl download.


> Update openssl download URI
> ---
>
> Key: GEODE-2992
> URL: https://issues.apache.org/jira/browse/GEODE-2992
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> It changed again for older versions...
> https://www.openssl.org/source/old/1.0.1/openssl-1.0.1u.tar.gz



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2992) Update openssl download URI

[Ernest Burghardt (JIRA)]

Ernest Burghardt created GEODE-2992:
---

 Summary: Update openssl download URI
 Key: GEODE-2992
 URL: https://issues.apache.org/jira/browse/GEODE-2992
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Ernest Burghardt


It changed again for older versions...
https://www.openssl.org/source/old/1.0.1/openssl-1.0.1u.tar.gz



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2990) fix testXmlCacheCreationWithPools

[Ernest Burghardt (JIRA)]

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

Ernest Burghardt updated GEODE-2990:

Component/s: native client

> fix testXmlCacheCreationWithPools
> -
>
> Key: GEODE-2990
> URL: https://issues.apache.org/jira/browse/GEODE-2990
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Fails due to an initialization ordering issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Proposal: Remove the "user-command-packages" system property

[Jinmei Liao]

both sides.

On Thu, May 25, 2017 at 2:16 PM, Darrel Schneider 
wrote:

> What JVM does this scanning? Is it just the top-level shell JVM or does it
> happen on the jmx-manager side?
>
> On Thu, May 25, 2017 at 1:01 PM, Jared Stewart 
> wrote:
>
> > It sounds like we're on the same page.
> >
> > The current behavior requires two pieces from a user who wants to add
> > commands:
> > 1) implement CommandMarker
> > 2) Add a system property pointing to the package of your class, or
> provide
> > a META-INF.services file pointing to your class
> >
> > The proposed behavior is to drop 2) and rely on 1) alone.
> >
> > On May 25, 2017 12:55 PM, "Udo Kohlmeyer"  wrote:
> >
> > What I meant was, given our hammer of choice for GFSH is Spring Shell,
> all
> > command definitions should be of type CommandMarker.
> >
> > Not sure how it loads the correct CommandMarker classes (for different
> > commands). But my gut feel is, have single way of doing something... KISS
> >
> >
> >
> > On 5/25/17 12:22, Jared Stewart wrote:
> >
> > > Can you clarify - I'm proposing we use *implements CommandMarker* alone
> > as
> > > the way to specify commands. What do we gain be *also* requiring a
> > > META-INF.services file?
> > >
> > > On May 25, 2017 12:18 PM, "Udo Kohlmeyer" 
> wrote:
> > >
> > > imo, I think that GFSH is Spring Shell, it should really only be
> commands
> > > that are registered inside of META-INF.services .. aka implements
> > > CommandMarker.
> > >
> > > This way we has standard simple way to specify commands.
> > >
> > > --Udo
> > >
> > >
> > >
> > > On 5/25/17 11:52, Jared Stewart wrote:
> > >
> > > I would like to propose that we eliminate the “user-command-packages”
> > >> system property, in favor of scanning the entire classpath to find
> > >> commands.
> > >>
> > >> To give more detail, Geode currently supports three ways to load GFSH
> > >> commands:
> > >> Scan the classpath for commands in "org.apache.geode.management.i
> > >> nternal.cli.commands”
> > >> Scan the classpath for commands in a package specified by a user via
> the
> > >> “user-command-packages” system property.
> > >> Scan the classpath for commands registered in files inside
> > >> META-INF.services (e.g. "geode-core/src/test/resources
> > >> /META-INF/services/org.springframework.shell.core.CommandMarker”)
> > >>
> > >> We have some bespoke code responsible for scanning the classpath
> > >> (ClasspathScanLoadHelper) that I am in the process of replacing with
> > >> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> > >> longer need to eagerly load all of the classes in the target package,
> I
> > >> don’t see any reason why a user should need to specify a
> > >> “user-command-package” property or a “META-INF/services” file.
> Instead,
> > >> we
> > >> should just scan the whole classpath and register any commands that we
> > >> find.
> > >>
> > >> Thoughts?
> > >>
> > >>
> >
>



-- 
Cheers

Jinmei

Re: Proposal: Remove the "user-command-packages" system property

[Darrel Schneider]

What JVM does this scanning? Is it just the top-level shell JVM or does it
happen on the jmx-manager side?

On Thu, May 25, 2017 at 1:01 PM, Jared Stewart  wrote:

> It sounds like we're on the same page.
>
> The current behavior requires two pieces from a user who wants to add
> commands:
> 1) implement CommandMarker
> 2) Add a system property pointing to the package of your class, or provide
> a META-INF.services file pointing to your class
>
> The proposed behavior is to drop 2) and rely on 1) alone.
>
> On May 25, 2017 12:55 PM, "Udo Kohlmeyer"  wrote:
>
> What I meant was, given our hammer of choice for GFSH is Spring Shell, all
> command definitions should be of type CommandMarker.
>
> Not sure how it loads the correct CommandMarker classes (for different
> commands). But my gut feel is, have single way of doing something... KISS
>
>
>
> On 5/25/17 12:22, Jared Stewart wrote:
>
> > Can you clarify - I'm proposing we use *implements CommandMarker* alone
> as
> > the way to specify commands. What do we gain be *also* requiring a
> > META-INF.services file?
> >
> > On May 25, 2017 12:18 PM, "Udo Kohlmeyer"  wrote:
> >
> > imo, I think that GFSH is Spring Shell, it should really only be commands
> > that are registered inside of META-INF.services .. aka implements
> > CommandMarker.
> >
> > This way we has standard simple way to specify commands.
> >
> > --Udo
> >
> >
> >
> > On 5/25/17 11:52, Jared Stewart wrote:
> >
> > I would like to propose that we eliminate the “user-command-packages”
> >> system property, in favor of scanning the entire classpath to find
> >> commands.
> >>
> >> To give more detail, Geode currently supports three ways to load GFSH
> >> commands:
> >> Scan the classpath for commands in "org.apache.geode.management.i
> >> nternal.cli.commands”
> >> Scan the classpath for commands in a package specified by a user via the
> >> “user-command-packages” system property.
> >> Scan the classpath for commands registered in files inside
> >> META-INF.services (e.g. "geode-core/src/test/resources
> >> /META-INF/services/org.springframework.shell.core.CommandMarker”)
> >>
> >> We have some bespoke code responsible for scanning the classpath
> >> (ClasspathScanLoadHelper) that I am in the process of replacing with
> >> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> >> longer need to eagerly load all of the classes in the target package, I
> >> don’t see any reason why a user should need to specify a
> >> “user-command-package” property or a “META-INF/services” file.  Instead,
> >> we
> >> should just scan the whole classpath and register any commands that we
> >> find.
> >>
> >> Thoughts?
> >>
> >>
>

[jira] [Created] (GEODE-2991) "destroy gateway-sender" command not in documentation

[Emily Yeh (JIRA)]

Emily Yeh created GEODE-2991:


 Summary: "destroy gateway-sender" command not in documentation
 Key: GEODE-2991
 URL: https://issues.apache.org/jira/browse/GEODE-2991
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: Emily Yeh


Documentation for the "destroy gateway-sender" command (handled by the 
destroyGatewaySender method under WanCommands.java) isn't available in the docs 
yet.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025385#comment-16025385
 ] 

ASF GitHub Bot commented on GEODE-2975:
---

Github user boglesby commented on the issue:

https://github.com/apache/geode/pull/538
  
This looks good for these xmls:
```

```
```

```
it still throws a ClassCastException for this, though:
```

```
I'm not sure if thats a problem or if its ok.




> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #538: GEODE-2975: Change the location of the lucene xsd

[boglesby]

Github user boglesby commented on the issue:

https://github.com/apache/geode/pull/538
  
This looks good for these xmls:
```

```
```

```
it still throws a ClassCastException for this, though:
```

```
I'm not sure if thats a problem or if its ok.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (GEODE-2944) lucene queries on String values (vs. objects) requires obscure/undocumented defaultField (__REGION_VALUE_FIELD)

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2944.

   Resolution: Fixed
Fix Version/s: 1.2.0

> lucene queries on String values (vs. objects) requires obscure/undocumented 
> defaultField (__REGION_VALUE_FIELD)
> ---
>
> Key: GEODE-2944
> URL: https://issues.apache.org/jira/browse/GEODE-2944
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> When a lucene index is created, one must indicate the field to create the 
> index on.  When the object value is a simple String, that must be specified 
> as --field=__REGION_VALUE_FIELD.
> For example,
> create lucene index --name=newIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> However, the lucene help text (for the gfsh command) does not provide this 
> detail.  In addition, it seems that when executing a lucene search, this must 
> be entered again as --defaultField=__REGION_VALUE_FIELD.
> While this is probably not something one would use in production, I imagine 
> it will be used by developers experimenting with Lucene, so we should 
> consider adding this to the help text.
> {noformat}
> gfsh>help create lucene index
> NAME
> create lucene index
> IS AVAILABLE
> true
> SYNOPSIS
> Create a lucene index that can be used to execute queries.
> SYNTAX
> create lucene index --name=value --region=value --field=value(,value)* 
> [--analyzer=value(,value)*]
> PARAMETERS
> name
> Name of the lucene index to create.
> Required: true
> region
> Name/Path of the region on which to create the lucene index.
> Required: true
> field
> fields on the region values which are stored in the lucene index.
> Required: true
> analyzer
> Type of the analyzer for each field.
> Required: false
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2818) add alias to any command's options that involves "group", "member", "jar"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025357#comment-16025357
 ] 

ASF GitHub Bot commented on GEODE-2818:
---

GitHub user YehEmily opened a pull request:

https://github.com/apache/geode/pull/539

GEODE-2818: add alias to any command's options that involves "group", 
"member", "jar"

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/YehEmily/geode synonyms

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/539.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #539


commit 01c5119654f27a254f8fb334b9fe8a2d5c4039ac
Author: YehEmily 
Date:   2017-05-23T19:27:40Z

GEODE-2977: make group/name option values consistent

commit 2076f03d8cd3748f204518c47b3a6245f9f6a714
Author: YehEmily 
Date:   2017-05-25T19:18:45Z

Edited command files to allow either 'group' or 'groups' and 'member' or 
'members




> add alias to any command's options that involves "group", "member", "jar"
> -
>
> Key: GEODE-2818
> URL: https://issues.apache.org/jira/browse/GEODE-2818
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, gfsh
>Reporter: Jinmei Liao
>
> Or anything that would have confusion about if we are going to use singular 
> or plural at all.
> 1) add alias for those options
> 2) make sure it parameter type is an array type, some method only accepts a 
> string and split it inside the command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2818) add alias to any command's options that involves "group", "member", "jar"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025358#comment-16025358
 ] 

ASF GitHub Bot commented on GEODE-2818:
---

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/539
  
Precheckin pending!


> add alias to any command's options that involves "group", "member", "jar"
> -
>
> Key: GEODE-2818
> URL: https://issues.apache.org/jira/browse/GEODE-2818
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, gfsh
>Reporter: Jinmei Liao
>
> Or anything that would have confusion about if we are going to use singular 
> or plural at all.
> 1) add alias for those options
> 2) make sure it parameter type is an array type, some method only accepts a 
> string and split it inside the command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #539: GEODE-2818: add alias to any command's options that involv...

[YehEmily]

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/539
  
Precheckin pending!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #539: GEODE-2818: add alias to any command's options that...

[YehEmily]

GitHub user YehEmily opened a pull request:

https://github.com/apache/geode/pull/539

GEODE-2818: add alias to any command's options that involves "group", 
"member", "jar"

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/YehEmily/geode synonyms

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/539.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #539


commit 01c5119654f27a254f8fb334b9fe8a2d5c4039ac
Author: YehEmily 
Date:   2017-05-23T19:27:40Z

GEODE-2977: make group/name option values consistent

commit 2076f03d8cd3748f204518c47b3a6245f9f6a714
Author: YehEmily 
Date:   2017-05-25T19:18:45Z

Edited command files to allow either 'group' or 'groups' and 'member' or 
'members




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2941) Pulse documentation is outdated

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025348#comment-16025348
 ] 

ASF subversion and git services commented on GEODE-2941:


Commit 7b34cfd9fd7865ee30f2d1518977b3c7bce294a4 in geode's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7b34cfd ]

GEODE-2941 Update Pulse documentation


> Pulse documentation is outdated
> ---
>
> Key: GEODE-2941
> URL: https://issues.apache.org/jira/browse/GEODE-2941
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Jinmei Liao
>Assignee: Dave Barnes
>
> the pulse documentation:
> http://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_523F6DE33FE54307BBE8F83BB7D9355D
> is no longer accurate anymore.
> 1. jmxUsername and jmxpassword no long applies
> 2. the logging configurations has changed too.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2944) lucene queries on String values (vs. objects) requires obscure/undocumented defaultField (__REGION_VALUE_FIELD)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025334#comment-16025334
 ] 

ASF subversion and git services commented on GEODE-2944:


Commit b7faa083aa9da5a9e7c3c579584be8f28faae02d in geode's branch 
refs/heads/develop from [~DivineEnder]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b7faa08 ]

GEODE-2944: Added __REGION_VALUE_FIELD explanation to lucene create index help

This closes #533


> lucene queries on String values (vs. objects) requires obscure/undocumented 
> defaultField (__REGION_VALUE_FIELD)
> ---
>
> Key: GEODE-2944
> URL: https://issues.apache.org/jira/browse/GEODE-2944
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: David Anuta
>
> When a lucene index is created, one must indicate the field to create the 
> index on.  When the object value is a simple String, that must be specified 
> as --field=__REGION_VALUE_FIELD.
> For example,
> create lucene index --name=newIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> However, the lucene help text (for the gfsh command) does not provide this 
> detail.  In addition, it seems that when executing a lucene search, this must 
> be entered again as --defaultField=__REGION_VALUE_FIELD.
> While this is probably not something one would use in production, I imagine 
> it will be used by developers experimenting with Lucene, so we should 
> consider adding this to the help text.
> {noformat}
> gfsh>help create lucene index
> NAME
> create lucene index
> IS AVAILABLE
> true
> SYNOPSIS
> Create a lucene index that can be used to execute queries.
> SYNTAX
> create lucene index --name=value --region=value --field=value(,value)* 
> [--analyzer=value(,value)*]
> PARAMETERS
> name
> Name of the lucene index to create.
> Required: true
> region
> Name/Path of the region on which to create the lucene index.
> Required: true
> field
> fields on the region values which are stored in the lucene index.
> Required: true
> analyzer
> Type of the analyzer for each field.
> Required: false
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #533: GEODE-2944: Added __REGION_VALUE_FIELD explanation ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/533


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2944) lucene queries on String values (vs. objects) requires obscure/undocumented defaultField (__REGION_VALUE_FIELD)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025335#comment-16025335
 ] 

ASF GitHub Bot commented on GEODE-2944:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/533


> lucene queries on String values (vs. objects) requires obscure/undocumented 
> defaultField (__REGION_VALUE_FIELD)
> ---
>
> Key: GEODE-2944
> URL: https://issues.apache.org/jira/browse/GEODE-2944
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: David Anuta
>
> When a lucene index is created, one must indicate the field to create the 
> index on.  When the object value is a simple String, that must be specified 
> as --field=__REGION_VALUE_FIELD.
> For example,
> create lucene index --name=newIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> However, the lucene help text (for the gfsh command) does not provide this 
> detail.  In addition, it seems that when executing a lucene search, this must 
> be entered again as --defaultField=__REGION_VALUE_FIELD.
> While this is probably not something one would use in production, I imagine 
> it will be used by developers experimenting with Lucene, so we should 
> consider adding this to the help text.
> {noformat}
> gfsh>help create lucene index
> NAME
> create lucene index
> IS AVAILABLE
> true
> SYNOPSIS
> Create a lucene index that can be used to execute queries.
> SYNTAX
> create lucene index --name=value --region=value --field=value(,value)* 
> [--analyzer=value(,value)*]
> PARAMETERS
> name
> Name of the lucene index to create.
> Required: true
> region
> Name/Path of the region on which to create the lucene index.
> Required: true
> field
> fields on the region values which are stored in the lucene index.
> Required: true
> analyzer
> Type of the analyzer for each field.
> Required: false
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2975) Attributes are not validated in lucene xml configuration

[Joey McAllister (JIRA)]

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

Joey McAllister updated GEODE-2975:
---
Component/s: docs

> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025325#comment-16025325
 ] 

ASF GitHub Bot commented on GEODE-2975:
---

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/538
  
@metatype - Yes, we'll need to update the website as well, the location of 
the xsd is also wrong on the website, but for different reasons.


> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #538: GEODE-2975: Change the location of the lucene xsd

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/538
  
@metatype - Yes, we'll need to update the website as well, the location of 
the xsd is also wrong on the website, but for different reasons.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025321#comment-16025321
 ] 

ASF GitHub Bot commented on GEODE-2975:
---

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/538
  
Does this also affect the xsd location on http://geode.apache.org?


> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #538: GEODE-2975: Change the location of the lucene xsd

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/538
  
Does this also affect the xsd location on http://geode.apache.org?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025312#comment-16025312
 ] 

ASF GitHub Bot commented on GEODE-2975:
---

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/538
  
@nabarunnag @boglesby


> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #538: GEODE-2975: Change the location of the lucene xsd

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/538
  
@nabarunnag @boglesby


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025308#comment-16025308
 ] 

ASF GitHub Bot commented on GEODE-2975:
---

GitHub user upthewaterspout opened a pull request:

https://github.com/apache/geode/pull/538

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [X] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [X] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [X] Is your initial contribution a single, squashed commit?

- [X] Does `gradlew build` run cleanly?

- [X] Have you written or updated unit tests to verify your changes?

- [X] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/geode feature/GEODE-2975

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/538.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #538


commit 313febd9eb1cc2b89ab790d00183010b9d5d27b2
Author: Dan Smith 
Date:   2017-05-25T20:05:23Z

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.




> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #538: GEODE-2975: Change the location of the lucene xsd

[upthewaterspout]

GitHub user upthewaterspout opened a pull request:

https://github.com/apache/geode/pull/538

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [X] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [X] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [X] Is your initial contribution a single, squashed commit?

- [X] Does `gradlew build` run cleanly?

- [X] Have you written or updated unit tests to verify your changes?

- [X] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/geode feature/GEODE-2975

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/538.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #538


commit 313febd9eb1cc2b89ab790d00183010b9d5d27b2
Author: Dan Smith 
Date:   2017-05-25T20:05:23Z

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2990) fix testXmlCacheCreationWithPools

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025302#comment-16025302
 ] 

ASF subversion and git services commented on GEODE-2990:


Commit 6708bf397485714674365c11ca9b0b9b90a8ff0f in geode-native's branch 
refs/heads/develop from [~eburghardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=6708bf3 ]

GEODE-2990: fix for testXMLCreationWithPools test failure


> fix testXmlCacheCreationWithPools
> -
>
> Key: GEODE-2990
> URL: https://issues.apache.org/jira/browse/GEODE-2990
> Project: Geode
>  Issue Type: Bug
>Reporter: Ernest Burghardt
>
> Fails due to an initialization ordering issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Proposal: Remove the "user-command-packages" system property

[Jared Stewart]

It sounds like we're on the same page.

The current behavior requires two pieces from a user who wants to add
commands:
1) implement CommandMarker
2) Add a system property pointing to the package of your class, or provide
a META-INF.services file pointing to your class

The proposed behavior is to drop 2) and rely on 1) alone.

On May 25, 2017 12:55 PM, "Udo Kohlmeyer"  wrote:

What I meant was, given our hammer of choice for GFSH is Spring Shell, all
command definitions should be of type CommandMarker.

Not sure how it loads the correct CommandMarker classes (for different
commands). But my gut feel is, have single way of doing something... KISS



On 5/25/17 12:22, Jared Stewart wrote:

> Can you clarify - I'm proposing we use *implements CommandMarker* alone as
> the way to specify commands. What do we gain be *also* requiring a
> META-INF.services file?
>
> On May 25, 2017 12:18 PM, "Udo Kohlmeyer"  wrote:
>
> imo, I think that GFSH is Spring Shell, it should really only be commands
> that are registered inside of META-INF.services .. aka implements
> CommandMarker.
>
> This way we has standard simple way to specify commands.
>
> --Udo
>
>
>
> On 5/25/17 11:52, Jared Stewart wrote:
>
> I would like to propose that we eliminate the “user-command-packages”
>> system property, in favor of scanning the entire classpath to find
>> commands.
>>
>> To give more detail, Geode currently supports three ways to load GFSH
>> commands:
>> Scan the classpath for commands in "org.apache.geode.management.i
>> nternal.cli.commands”
>> Scan the classpath for commands in a package specified by a user via the
>> “user-command-packages” system property.
>> Scan the classpath for commands registered in files inside
>> META-INF.services (e.g. "geode-core/src/test/resources
>> /META-INF/services/org.springframework.shell.core.CommandMarker”)
>>
>> We have some bespoke code responsible for scanning the classpath
>> (ClasspathScanLoadHelper) that I am in the process of replacing with
>> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
>> longer need to eagerly load all of the classes in the target package, I
>> don’t see any reason why a user should need to specify a
>> “user-command-package” property or a “META-INF/services” file.  Instead,
>> we
>> should just scan the whole classpath and register any commands that we
>> find.
>>
>> Thoughts?
>>
>>

Re: Proposal: Remove the "user-command-packages" system property

[Udo Kohlmeyer]

What I meant was, given our hammer of choice for GFSH is Spring Shell, 
all command definitions should be of type CommandMarker.


Not sure how it loads the correct CommandMarker classes (for different 
commands). But my gut feel is, have single way of doing something... KISS



On 5/25/17 12:22, Jared Stewart wrote:

Can you clarify - I'm proposing we use *implements CommandMarker* alone as
the way to specify commands. What do we gain be *also* requiring a
META-INF.services file?

On May 25, 2017 12:18 PM, "Udo Kohlmeyer"  wrote:

imo, I think that GFSH is Spring Shell, it should really only be commands
that are registered inside of META-INF.services .. aka implements
CommandMarker.

This way we has standard simple way to specify commands.

--Udo



On 5/25/17 11:52, Jared Stewart wrote:


I would like to propose that we eliminate the “user-command-packages”
system property, in favor of scanning the entire classpath to find commands.

To give more detail, Geode currently supports three ways to load GFSH
commands:
Scan the classpath for commands in "org.apache.geode.management.i
nternal.cli.commands”
Scan the classpath for commands in a package specified by a user via the
“user-command-packages” system property.
Scan the classpath for commands registered in files inside
META-INF.services (e.g. "geode-core/src/test/resources
/META-INF/services/org.springframework.shell.core.CommandMarker”)

We have some bespoke code responsible for scanning the classpath
(ClasspathScanLoadHelper) that I am in the process of replacing with
FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
longer need to eagerly load all of the classes in the target package, I
don’t see any reason why a user should need to specify a
“user-command-package” property or a “META-INF/services” file.  Instead, we
should just scan the whole classpath and register any commands that we find.

Thoughts?

Re: Proposal: Remove the "user-command-packages" system property

[Jinmei Liao]

+1 for scanning the whole classpath without eager loading.

On Thu, May 25, 2017 at 11:52 AM, Jared Stewart  wrote:

> I would like to propose that we eliminate the “user-command-packages”
> system property, in favor of scanning the entire classpath to find commands.
>
> To give more detail, Geode currently supports three ways to load GFSH
> commands:
> Scan the classpath for commands in "org.apache.geode.management.
> internal.cli.commands”
> Scan the classpath for commands in a package specified by a user via the
> “user-command-packages” system property.
> Scan the classpath for commands registered in files inside
> META-INF.services (e.g. "geode-core/src/test/resources/META-INF/services/
> org.springframework.shell.core.CommandMarker”)
>
> We have some bespoke code responsible for scanning the classpath
> (ClasspathScanLoadHelper) that I am in the process of replacing with
> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> longer need to eagerly load all of the classes in the target package, I
> don’t see any reason why a user should need to specify a
> “user-command-package” property or a “META-INF/services” file.  Instead, we
> should just scan the whole classpath and register any commands that we find.
>
> Thoughts?




-- 
Cheers

Jinmei

Re: Proposal: Remove the "user-command-packages" system property

[Jared Stewart]

Can you clarify - I'm proposing we use *implements CommandMarker* alone as
the way to specify commands. What do we gain be *also* requiring a
META-INF.services file?

On May 25, 2017 12:18 PM, "Udo Kohlmeyer"  wrote:

imo, I think that GFSH is Spring Shell, it should really only be commands
that are registered inside of META-INF.services .. aka implements
CommandMarker.

This way we has standard simple way to specify commands.

--Udo



On 5/25/17 11:52, Jared Stewart wrote:

> I would like to propose that we eliminate the “user-command-packages”
> system property, in favor of scanning the entire classpath to find commands.
>
> To give more detail, Geode currently supports three ways to load GFSH
> commands:
> Scan the classpath for commands in "org.apache.geode.management.i
> nternal.cli.commands”
> Scan the classpath for commands in a package specified by a user via the
> “user-command-packages” system property.
> Scan the classpath for commands registered in files inside
> META-INF.services (e.g. "geode-core/src/test/resources
> /META-INF/services/org.springframework.shell.core.CommandMarker”)
>
> We have some bespoke code responsible for scanning the classpath
> (ClasspathScanLoadHelper) that I am in the process of replacing with
> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> longer need to eagerly load all of the classes in the target package, I
> don’t see any reason why a user should need to specify a
> “user-command-package” property or a “META-INF/services” file.  Instead, we
> should just scan the whole classpath and register any commands that we find.
>
> Thoughts?
>

[jira] [Resolved] (GEODE-2952) gfsh doesn't support exact match lucene queries

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2952.

Resolution: Not A Problem

> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Proposal: Remove the "user-command-packages" system property

[Udo Kohlmeyer]

imo, I think that GFSH is Spring Shell, it should really only be 
commands that are registered inside of META-INF.services .. aka 
implements CommandMarker.


This way we has standard simple way to specify commands.

--Udo


On 5/25/17 11:52, Jared Stewart wrote:

I would like to propose that we eliminate the “user-command-packages” system 
property, in favor of scanning the entire classpath to find commands.

To give more detail, Geode currently supports three ways to load GFSH commands:
Scan the classpath for commands in 
"org.apache.geode.management.internal.cli.commands”
Scan the classpath for commands in a package specified by a user via the 
“user-command-packages” system property.
Scan the classpath for commands registered in files inside META-INF.services (e.g. 
"geode-core/src/test/resources/META-INF/services/org.springframework.shell.core.CommandMarker”)

We have some bespoke code responsible for scanning the classpath 
(ClasspathScanLoadHelper) that I am in the process of replacing with 
FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no longer 
need to eagerly load all of the classes in the target package, I don’t see any 
reason why a user should need to specify a “user-command-package” property or a 
“META-INF/services” file.  Instead, we should just scan the whole classpath and 
register any commands that we find.

Thoughts?

[jira] [Commented] (GEODE-2952) gfsh doesn't support exact match lucene queries

[David Anuta (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025244#comment-16025244
 ] 

David Anuta commented on GEODE-2952:


Turns out you can do exact query matches using double quotes, but it is 
dependent upon the quotes used when actually passing the query string to the 
GFSH shell. Below is an example exact query matching on the string "police 
dept" within a test index which contains both the exact string "police dept" 
and the string "police".

{noformat}
describe lucene index --name index --region region

Index Name | Region Path | Server Name | Indexed Fields | 
Field Analyzer  |   Status| Query Executions | Updates | 
Commits | Documents

-- | --- | --- | -- | 
--- | --- |  | 
--- | --- | -

index  | /region | s1  | [__REGION_VALUE_FIELD] | 
{__REGION_VALUE_FIELD=StandardAnalyzer} | Initialized | 0| 0
   | 0   | 0

gfsh>put --region region --key 1 --value="police dept"

Result  : true

Key Class   : java.lang.String

Key : 1

Value Class : java.lang.String

Old Value   : 





gfsh>put --region region --key 2 --value="police"

Result  : true

Key Class   : java.lang.String

Key : 2

Value Class : java.lang.String

Old Value   : 



gfsh>search lucene --name index --region region --queryStrings='"police dept"' 
--defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region --queryStrings='police dept' 
--defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

2   | police  | 0.2876821

1   | police dept | 0.51623213



gfsh>put --region region --key 3 --value="ABC"

Result  : true

Key Class   : java.lang.String

Key : 3

Value Class : java.lang.String

Old Value   : 





gfsh>search lucene --name index --region region 
--queryStrings='__REGION_VALUE_FIELD:"police dept"' --defaultField 
__REGION_VALUE_FIELD

key |value| score

--- | --- | --

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region 
--queryStrings='__REGION_VALUE_FIELD:"police dept" OR 
__REGION_VALUE_FIELD:"ABC"' --defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

3   | ABC | 0.2876821

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region 
--queryStrings='__REGION_VALUE_FIELD:"police dept" OR 
__REGION_VALUE_FIELD:\'ABC\'' --defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

3   | ABC | 0.2876821

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region 
--queryStrings="__REGION_VALUE_FIELD:'police dept' OR 
__REGION_VALUE_FIELD:'ABC'" --defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

2   | police  | 0.2876821

3   | ABC | 0.2876821

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region 
--queryStrings="__REGION_VALUE_FIELD:\"police dept\" OR 
__REGION_VALUE_FIELD:'ABC'" --defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

3   | ABC | 0.2876821

1   | police dept | 0.51623213

{noformat}

As you can see, the double quotations must be used within the actual query 
string parameter passed to the queryStrings flag in order to get a proper exact 
match on the query string through the API. In the example given in the 
description of this issue, the 'Police Dept' case failed to exact match because 
there were no double quotes around the Police Dept string and the '\"Police 
Dept\"' string failed because the double quotes were escaped when they did not 
need to be. The formatting for exact string matching on the string Police Dept 
right now must be either '"Police Dept"' (no escape characters are needed for 
parsing) or "\"Police Dept\"" (escape characters needed for flag parsing).

> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:

[jira] [Commented] (GEODE-2957) null used as a default parameter when specifying analyzers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025236#comment-16025236
 ] 

ASF GitHub Bot commented on GEODE-2957:
---

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/537
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


> null used as a default parameter when specifying analyzers
> --
>
> Key: GEODE-2957
> URL: https://issues.apache.org/jira/browse/GEODE-2957
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> null seems to be the way to specify using the default 
> StandardKeywordAnalyzer. This can be used when specifying a long list of 
> field/analyzers.  
> So the line may look like 
> --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer}
>  We should probably change that to default or some other keyword.  null seems 
> a bit confusing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #537: GEODE-2957: Added DEFAULT as a standardAnalyzer keyword sp...

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/537
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2957) null used as a default parameter when specifying analyzers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025235#comment-16025235
 ] 

ASF GitHub Bot commented on GEODE-2957:
---

GitHub user DivineEnder opened a pull request:

https://github.com/apache/geode/pull/537

GEODE-2957: Added DEFAULT as a standardAnalyzer keyword specifier whe…

…n creating Lucene index

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2957

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/537.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #537


commit 7b0543a7325ee08fb9b91710c9b406cc41f75451
Author: David Anuta 
Date:   2017-05-25T19:03:43Z

GEODE-2957: Added DEFAULT as a standardAnalyzer keyword specifier when 
creating Lucene index




> null used as a default parameter when specifying analyzers
> --
>
> Key: GEODE-2957
> URL: https://issues.apache.org/jira/browse/GEODE-2957
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> null seems to be the way to specify using the default 
> StandardKeywordAnalyzer. This can be used when specifying a long list of 
> field/analyzers.  
> So the line may look like 
> --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer}
>  We should probably change that to default or some other keyword.  null seems 
> a bit confusing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #537: GEODE-2957: Added DEFAULT as a standardAnalyzer key...

[DivineEnder]

GitHub user DivineEnder opened a pull request:

https://github.com/apache/geode/pull/537

GEODE-2957: Added DEFAULT as a standardAnalyzer keyword specifier whe…

…n creating Lucene index

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2957

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/537.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #537


commit 7b0543a7325ee08fb9b91710c9b406cc41f75451
Author: David Anuta 
Date:   2017-05-25T19:03:43Z

GEODE-2957: Added DEFAULT as a standardAnalyzer keyword specifier when 
creating Lucene index




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Hitesh Khamesra]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59546/#review176113
---




geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
Line 196 (original), 196 (patched)


Removed it. here we validate hist only



geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
Line 277 (original), 281 (patched)


Removed commented code



geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
Line 1555 (original), 1555 (patched)


This is just for compare purpose.



geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
Line 131 (original), 132 (patched)


Yes, that's the change.Removed commented code



geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
Lines 234 (patched)


line 131; but then hostname will be there. What I am reading is that at 
this point either host/hostname will be there



geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
Lines 278 (patched)


Ip should be fine. This can throw exception when host/hostname is not 
appropriate.



geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
Lines 346 (patched)


If locator host is still not avialable then server won't be able to join 
the cluster.


- Hitesh Khamesra


On May 25, 2017, 7:06 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59546/
> ---
> 
> (Updated May 25, 2017, 7:06 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exist or not. Now we 
> have remove this verification as in cloud environment host may not available 
> for time being. 
> 
> Patch from Bruce. Modified couple of tests.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
>  c1bfc93 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
>  01c6157 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
>  5ab1bed 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
>  1dc2fd1 
>   
> geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
>  dc73f04 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
>  9f6c5fb 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d 
>   
> geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
>  d6d5d7c 
> 
> 
> Diff: https://reviews.apache.org/r/59546/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

[jira] [Reopened] (GEODE-2952) gfsh doesn't support exact match lucene queries

[David Anuta (JIRA)]

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

David Anuta reopened GEODE-2952:


> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Hitesh Khamesra]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59546/
---

(Updated May 25, 2017, 7:06 p.m.)


Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo Kohlmeyer.


Changes
---

Updated diff; removed commented code


Repository: geode


Description
---

We configure locator list to start the cache. This locator list is validated 
while creating the cache. We verify whether locator host exist or not. Now we 
have remove this verification as in cloud environment host may not available 
for time being. 

Patch from Bruce. Modified couple of tests.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
 c1bfc93 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
 01c6157 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 7caad3f 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
 5ab1bed 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
 1dc2fd1 
  
geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
 dc73f04 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
 9f6c5fb 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d 
  
geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
 d6d5d7c 


Diff: https://reviews.apache.org/r/59546/diff/2/

Changes: https://reviews.apache.org/r/59546/diff/1-2/


Testing
---


Thanks,

Hitesh Khamesra

Proposal: Remove the "user-command-packages" system property

[Jared Stewart]

I would like to propose that we eliminate the “user-command-packages” system 
property, in favor of scanning the entire classpath to find commands.

To give more detail, Geode currently supports three ways to load GFSH commands: 
Scan the classpath for commands in 
"org.apache.geode.management.internal.cli.commands”
Scan the classpath for commands in a package specified by a user via the 
“user-command-packages” system property. 
Scan the classpath for commands registered in files inside META-INF.services 
(e.g. 
"geode-core/src/test/resources/META-INF/services/org.springframework.shell.core.CommandMarker”)
 

We have some bespoke code responsible for scanning the classpath 
(ClasspathScanLoadHelper) that I am in the process of replacing with 
FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no longer 
need to eagerly load all of the classes in the target package, I don’t see any 
reason why a user should need to specify a “user-command-package” property or a 
“META-INF/services” file.  Instead, we should just scan the whole classpath and 
register any commands that we find.

Thoughts?

[jira] [Resolved] (GEODE-2952) gfsh doesn't support exact match lucene queries

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2952.

   Resolution: Fixed
Fix Version/s: 1.2.0

> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2950.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025159#comment-16025159
 ] 

ASF GitHub Bot commented on GEODE-2950:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/532


> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #532: GEODE-2950: Adding validation checks on create Luce...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/532


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (GEODE-2990) fix testXmlCacheCreationWithPools

[Ernest Burghardt (JIRA)]

Ernest Burghardt created GEODE-2990:
---

 Summary: fix testXmlCacheCreationWithPools
 Key: GEODE-2990
 URL: https://issues.apache.org/jira/browse/GEODE-2990
 Project: Geode
  Issue Type: Bug
Reporter: Ernest Burghardt


Fails due to an initialization ordering issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025158#comment-16025158
 ] 

ASF subversion and git services commented on GEODE-2950:


Commit c793f74c07c3488ba188ed927144be688bd50b19 in geode's branch 
refs/heads/develop from [~DivineEnder]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c793f74 ]

GEODE-2950: Adding validation checks on create lucene index parameter names

This closes #532


> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2988) create a security example

[Joey McAllister (JIRA)]

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

Joey McAllister updated GEODE-2988:
---
Component/s: docs

> create a security example
> -
>
> Key: GEODE-2988
> URL: https://issues.apache.org/jira/browse/GEODE-2988
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, security
>Reporter: Swapnil Bawaskar
>
> create an example for demonstrating security. The example should show how to 
> leverage the {{security-manager}}, register the {{AuthInitializer}} on the 
> client and have recipes for various roles.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2989) Improve mechanism for scanning the classpath to find gfsh commands

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2989:


Assignee: Jared Stewart

> Improve mechanism for scanning the classpath to find gfsh commands
> --
>
> Key: GEODE-2989
> URL: https://issues.apache.org/jira/browse/GEODE-2989
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The current mechanism for scanning the classpath to find gfsh commands 
> (ClasspathScanLoadHelper) has some deficiencies, including: 
> 1) Commands can only be scanned for in an exact package 
> ("org.apache.geode.management.internal.cli.commands").  We can't pick up 
> commands from any subpackages,  prevents us from better organizing the 
> package structure of our commands (e.g. 
> "org.apache.geode.management.internal.cli.commands.lifecycle").
> 2) All classes in the target package are eagerly loaded, whether or not they 
> contain commands.  
> Both of these deficiencies can be removed if we replace the implementation of 
> ClasspathScanLoadHelper with calls to FastClasspathScanner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2989) Improve mechanism for scanning the classpath to find gfsh commands

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2989:


 Summary: Improve mechanism for scanning the classpath to find gfsh 
commands
 Key: GEODE-2989
 URL: https://issues.apache.org/jira/browse/GEODE-2989
 Project: Geode
  Issue Type: Improvement
  Components: gfsh, management
Reporter: Jared Stewart


The current mechanism for scanning the classpath to find gfsh commands 
(ClasspathScanLoadHelper) has some deficiencies, including: 

1) Commands can only be scanned for in an exact package 
("org.apache.geode.management.internal.cli.commands").  We can't pick up 
commands from any subpackages,  prevents us from better organizing the package 
structure of our commands (e.g. 
"org.apache.geode.management.internal.cli.commands.lifecycle").

2) All classes in the target package are eagerly loaded, whether or not they 
contain commands.  

Both of these deficiencies can be removed if we replace the implementation of 
ClasspathScanLoadHelper with calls to FastClasspathScanner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2988) create a security example

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2988:
---

 Summary: create a security example
 Key: GEODE-2988
 URL: https://issues.apache.org/jira/browse/GEODE-2988
 Project: Geode
  Issue Type: Sub-task
  Components: security
Reporter: Swapnil Bawaskar


create an example for demonstrating security. The example should show how to 
leverage the {{security-manager}}, register the {{AuthInitializer}} on the 
client and have recipes for various roles.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Galen O'Sullivan]

> On May 25, 2017, 5:51 p.m., Galen O'Sullivan wrote:
> > geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
> > Lines 346 (patched)
> > 
> >
> > Could this be split into two tests, one of which continues and the 
> > other of which triggers a failure later on?

That is, could one of the tests test what happens when we try to evaluate the 
host later? (See my question in the overall review comment about whether we 
ever give up).


- Galen


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59546/#review176020
---


On May 25, 2017, 5:12 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59546/
> ---
> 
> (Updated May 25, 2017, 5:12 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exist or not. Now we 
> have remove this verification as in cloud environment host may not available 
> for time being. 
> 
> Patch from Bruce. Modified couple of tests.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
>  c1bfc93 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
>  01c6157 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
>  5ab1bed 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
>  1dc2fd1 
>   
> geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
>  dc73f04 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
>  9f6c5fb 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d 
>   
> geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
>  d6d5d7c 
> 
> 
> Diff: https://reviews.apache.org/r/59546/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Galen O'Sullivan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59546/#review176020
---



Good work! I have a few minor comments and a couple of things I'm concerned 
about because I don't understand the rest of the system so well. Maybe you can 
help clarify for me.

It looks like the host will be set when we call `getHost()`. Do we want to 
expire hosts or give up looking for them? Are callers expecting an existing 
locator to be valid and connected? Will this cause delays as we iterate through 
locators that have been dropped or were never up? 

I remember there being a ticket recently to save hostnames for Cache members 
and pass the hostnames from the Locator. I'm wondering if it would make sense 
to have a shared `lazilyEvaluatedHost` class? I don't think that should hold 
this up, though.


geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
Line 196 (original), 196 (patched)


I'd rather this code be deleted than commented out.
Can you explain why we're using the hostname rather than the host?



geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
Line 1555 (original), 1555 (patched)


Will this mess with anything that depends on the canonical locator 
serialization?



geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
Line 131 (original), 132 (patched)


It looks like taking out this exception will cause us to behave differently 
if we can't look up the hostname. There's a lot going on here. Are we trying to 
retain the hostname for reconnects or keep trying to connect here?



geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
Lines 234 (patched)


`host` can be null, see line 131 of DistributionLocatorId.java.

It looks like `hostname` can't be null if we call the `String` constructor, 
but it can if we call the IP and port constructor.

I would like to unify the constructors if we can, because it looks like the 
string-only form works differently from the other form, but it's not clear what 
the constraints on `bindAddress` are in the other form.



geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
Lines 278 (patched)


What makes the new code able to throw an exception here? We could still 
specify locators by IP before, right?



geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
Lines 346 (patched)


Could this be split into two tests, one of which continues and the other of 
which triggers a failure later on?


- Galen O'Sullivan


On May 25, 2017, 5:12 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59546/
> ---
> 
> (Updated May 25, 2017, 5:12 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exist or not. Now we 
> have remove this verification as in cloud environment host may not available 
> for time being. 
> 
> Patch from Bruce. Modified couple of tests.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
>  c1bfc93 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
>  01c6157 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
>  5ab1bed 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
>  1dc2fd1 
>   
> geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
>  dc73f04 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
>  9f6c5fb 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d 
>   
> geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
>  d6d5d7c 
> 
> 
> Diff: https://reviews.apache.org/r/59546/diff/1/
> 
> 
> 

[jira] [Created] (GEODE-2987) document finer grained security migration

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2987:
---

 Summary: document finer grained security migration
 Key: GEODE-2987
 URL: https://issues.apache.org/jira/browse/GEODE-2987
 Project: Geode
  Issue Type: Sub-task
  Components: docs
Reporter: Swapnil Bawaskar


We need to document how a user will migrate to the new finer grained security 
model from that in 1.2 release.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: What to do with Singletons

[Galen M O'Sullivan]

>
> But we should probably create another thread to talk about it to keep this
> one focused on the singletons discussion.
>
+1


How far can we go down the path of cleaning up Singletons without having a
> DI framework in the mix?


We can do DI without a framework, by just passing the dependencies that a
function needs. Hopefully, this means that coders working on Geode can
think carefully about the requirements for a class or method call and by
thinking about requirements we get a better idea of our architecture and
what sections of the code can be separated.

If it gets too complicated (we start seeing a lot of places where some
inner call in the call graph requires something from further outside), we
can use a framework. I'd rather iterate in a way that's more lightweight
until we start needing something heavier.

[jira] [Resolved] (GEODE-2955) gfsh create lucene index command should validate the region name parameter

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2955.

   Resolution: Fixed
Fix Version/s: 1.2.0

> gfsh create lucene index command should validate the region name parameter
> --
>
> Key: GEODE-2955
> URL: https://issues.apache.org/jira/browse/GEODE-2955
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> The gfsh command to create the lucene index should not only validate the 
> lucene index name but also the region name.  It currently is possible to pass 
> an invalid region name as a parameter.  The region will then not be able to 
> be created.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: What to do with Singletons

[Udo Kohlmeyer]

+1 to moving the "OOTB" discussion onto another thread. Very 
distracting, interjecting another topic, into a completely not related 
email thread.


MAYBE, there could be a list of ootb functions that the community would 
like to support/write. This should be done on the Apache Geode Wiki.



On 5/25/17 09:19, William Markito Oliveira wrote:

+1 for Geode functions as well.

Back on the day, I've talked with Barry about it and we got a few basic
ones into this repository.

https://github.com/markito/geode-functions

But we should probably create another thread to talk about it to keep this
one focused on the singletons discussion.

On Thu, May 25, 2017 at 8:45 AM, Wes Williams  wrote:


+1 to utility functions

*Wes Williams | Pivotal Advisory **Data Engineer*
781.606.0325
http://pivotal.io/big-data/pivotal-gemfire

On Wed, May 24, 2017 at 4:59 PM, John Blum  wrote:


On a side but related note, it would be nice if Geode had the notion of
useful, "canned" Functions provided OOTB.  Some of the *Gfsh* functions
would be quite useful for applications in fact, or particularly for
framework/tools to use as well.  Sometime ago I sent a list of Functions

I

thought would be nice to have.

Food for thought.

On Wed, May 24, 2017 at 1:41 PM, Kirk Lund  wrote:


Thanks for pointing out that DistributionManager is internal -- I

forgot

about that. I'm primarily concerned with internal Functions, such as

those

for GFSH commands, so maybe an internal version of FunctionContext

which

exposes more would be good for those.

On Wed, May 24, 2017 at 11:39 AM, Darrel Schneider <

dschnei...@pivotal.io>

wrote:


FunctionContext is an external interface so it can not expose

internal

interfaces like DistributionManager.
But it could expose Cache. DistributedSystem is external so you could

have

it exposed from FunctionContext but it is already exposed from Cache.
SecurityService is also internal.
Are you thinking that for internal Functions you would cast

FunctionContext

to an internal that would then expose these internal classes?



On Thu, May 18, 2017 at 5:13 PM, Kirk Lund  wrote:


I've been digging through our code with close attention to the

singletons.

I believe the majority of singletons in Geode exist for two main

reasons:

1) Insufficient context or lack of service lookup for Function,
DistributionMessage and (Client)Command implementations.

2) Poor OO design. This is where you see code in one class invoking
concrete methods on another class outside of its concerns. Many of

these

need to be teased apart and replaced with some sort of Observer

that

isolates the reaction from the source of the originating event.

Right now my focus is on #1 because that's the area that's

currently

an

obstacle for me.

Function, DistributionMessage and (Client)Command classes need to

have

more

context provided to them (Cache, Security, etc) or they need a

better

mechanism to look up these services. Currently these classes reach

out

to

singletons in order to "get" what they need.

*A) Function*

The main entry-point which injects services into the Function is:

public void execute(FunctionContext context);

The FunctionContext needs to provide the service(s) that any

Function

might

require. This could include Cache, DistributionManager and maybe
SecurityService (anything else?).

*B) (Peer-to-peer) DistributionMessage*

The main entry-point which injects services into the

DistributionMessage

is:

protected abstract void process(DistributionManager dm);

We could provide multiple arguments or a single new

DistributionContext

which then provides DistributionManager and Cache (anything else?).

*C) (Client) Command*

The main entry-point which injects services into the Command is:

public void execute(Message msg, ServerConnection servConn);

ServerConnection is huge but it does already expose Cache.

BaseCommand

is

the only Command that implements "execute" and it defines a new

entry-point

for injection:

abstract public void cmdExecute(Message msg, ServerConnection

servConn,

long start) throws IOException, ClassNotFoundException,
InterruptedException;

We might want to clean that up and define a new CommandContext

which

provides the Cache or anything else that the Command may need.

Thoughts or additional ideas?




--
-John
john.blum10101 (skype)

Re: Geode Nightly build is consistently RED

[Udo Kohlmeyer]

@Kirk, I share your concern. If the builds are RED then we should 
address them. Ideally there should be no flaky tests, but given the 
hyper-threaded nature of the beast, things can go wrong that are really 
hard to reproduce. Arguably, even those scenarios should be addressed, 
but if we wait for the perfect alignment of the planets to have a 
complete green run, then we would never release.


That said. I've accepted, that a clean run of all categories, other than 
flaky, to mean we had a "good" run. It would be awesome to collect some 
metrics (counts,etc.. ), on a weekly,monthly basis, about failing test 
(per category).


This way, we could hopefully identify "burning" failing tests, that need 
to be addressed with urgency.


--Udo


On 5/25/17 09:00, Anthony Baker wrote:

This is topic is very relevant given that we are working towards a 1.2.0 
release.  In order to release we need—at the very minimum--a clean pass through 
distributedTest.

Recently we’ve had some instability that has contributed to failing tests.

Anthony


On May 24, 2017, at 4:54 PM, Kirk Lund  wrote:

If other people are ignoring the results of the flakyTest target and that's
the reason that people do not want to add FlakyTest category to tests that
aren't currently marked with FlakyTest then here's my proposal... we delete
FlakyTest category (well actually just rename it) and replace it with
TestsThatFailMoreFrequentlyAndNeedToRunInFreshJVM category and we educate
all geode developers to NOT ignore the results. If the test keeps failing
when run in isolation under
"TestsThatFailMoreFrequentlyAndNeedToRunInFreshJVM" then that means it
needs to be fixed asap and not ignored. Thoughts?

On Wed, May 24, 2017 at 4:50 PM, Kirk Lund  wrote:


Geode Nightly build is staying consistently RED... each night the tests
that fail vary some. Do we still want to not add FlakyTest category to
these tests and just live with a RED nightly build?

What do you all want to do? Any ideas what to do to get it consistently
GREEN?

The only way I know to get it GREEN is either a) we drop everything we're
working on and fix flaky tests or b) we add FlakyTest category to flaky
tests. The flakyTest target still runs the FlakyTest tests but it does so
with a fresh JVM. In my opinion we should NOT ignore the results of
flakyTest (and I personally do not ignore these results). I think it's a
useful way to run DUnit tests that have special needs.

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Hitesh Khamesra]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59546/
---

(Updated May 25, 2017, 5:12 p.m.)


Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo Kohlmeyer.


Repository: geode


Description (updated)
---

We configure locator list to start the cache. This locator list is validated 
while creating the cache. We verify whether locator host exist or not. Now we 
have remove this verification as in cloud environment host may not available 
for time being. 

Patch from Bruce. Modified couple of tests.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
 c1bfc93 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
 01c6157 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 7caad3f 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
 5ab1bed 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
 1dc2fd1 
  
geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
 dc73f04 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
 9f6c5fb 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d 
  
geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
 d6d5d7c 


Diff: https://reviews.apache.org/r/59546/diff/1/


Testing
---


Thanks,

Hitesh Khamesra

[jira] [Resolved] (GEODE-2954) Old client gets null memberID in cache listener

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-2954.
-
Resolution: Fixed

> Old client gets null memberID in cache listener
> ---
>
> Key: GEODE-2954
> URL: https://issues.apache.org/jira/browse/GEODE-2954
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> I was doing backward compatibility testing and found a 1.0 client was getting 
> a null memberID in a cache listener
> {noformat}
> [info 2017/05/18 16:27:38.957 PDT  trout(bridgegemfire5_trout_2254:2254):1030 port 21051> tid=0x2f] 
> Invoked util.SilenceListener for key Object_7399: afterDestroy in edge1, pid 
> 2267, vmID 5, operation DESTROY
>  whereIWasRegistered: 2267
>  event.getKey(): Object_7399
>  event.getOldValue():  (contains 6 levels, aPrimitiveLong=6409636308677575978)>
>  event.getNewValue(): null
>  event.getOperation().isLoad(): false
>  event.getOperation().isLocalLoad(): false
>  event.getOperation().isNetLoad(): false
>  event.getOperation().isNetSearch(): false
>  event.isConcurrencyConflict(): false
>  event.getDistributedMember(): null
>  event.getCallbackArgument(): null
>  event.getRegion(): /testRegion
>  event.getOperation().isDistributed(): true
>  event.getOperation().isExpiration(): false
>  event.isOriginRemote(): true
> {noformat}
> This was in an old test suite whose testing infrastructure isn't in the Geode 
> repo.  I'm writing a unit test to reproduce the problem.
> If you look at EventID.java you can see that it catches IOExceptions in 
> deserializing the memberID of the event and returns null without logging the 
> problem.
> {code}
> try {
>   result = InternalDistributedMember.readEssentialData(dis);
> } catch (IOException e) {
>   // nothing can be done about this
> } catch (ClassNotFoundException e) {
>   // ditto
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2913) Update Lucene documentation

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-2913.

Resolution: Fixed

> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction 
> configured with local destroy. If using Lucene indexing, eviction can only be 
> configured with overflow to disk. In this case, only the region data is 
> overflowed to disk, *NOT* the Lucene index. An UnsupportedOperationException 
> is thrown:
> {quote}
> [error 2017/05/02 16:12:32.461 PDT  tid=0x1] 
> 

[GitHub] geode issue #536: GEODE-2977: make group/name option values consistent

[YehEmily]

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/536
  
Precheckin was successful!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024971#comment-16024971
 ] 

ASF GitHub Bot commented on GEODE-2977:
---

GitHub user YehEmily opened a pull request:

https://github.com/apache/geode/pull/536

GEODE-2977: make group/name option values consistent

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/YehEmily/geode groupname

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/536.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #536


commit 01c5119654f27a254f8fb334b9fe8a2d5c4039ac
Author: YehEmily 
Date:   2017-05-23T19:27:40Z

GEODE-2977: make group/name option values consistent




> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024973#comment-16024973
 ] 

ASF GitHub Bot commented on GEODE-2977:
---

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/536
  
Precheckin was successful!


> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)