copy files to servers

[Swapnil Bawaskar]

Some application may need to copy files to all the servers. These files
could either be data files or they could be configuration files needed by
the application or they could be jar files (that don't have functions but
have say, spring data geode jar files) that need to be on the server's
classpath.
We could accomplish this by enhancing the current gfsh "deploy" command to
accept any kind of file and write it to the servers file system OR create a
new gfsh "copy" command to copy any arbitrary file to the servers.
I would personally like to repurpose the deploy command but would like to
hear the community's opinion.

Thanks!

Re: copy files to servers

[Michael Stolz]

Are you thinking about adding a --destination= command option to
tell deploy that it's not a function and where to put it?

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Jan 6, 2017 5:38 AM, "Swapnil Bawaskar"  wrote:

> Some application may need to copy files to all the servers. These files
> could either be data files or they could be configuration files needed by
> the application or they could be jar files (that don't have functions but
> have say, spring data geode jar files) that need to be on the server's
> classpath.
> We could accomplish this by enhancing the current gfsh "deploy" command to
> accept any kind of file and write it to the servers file system OR create a
> new gfsh "copy" command to copy any arbitrary file to the servers.
> I would personally like to repurpose the deploy command but would like to
> hear the community's opinion.
>
> Thanks!
>

[jira] [Commented] (GEODE-2268) Store jar bytes in cluster configuration region

[Wes Williams (JIRA)]

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

Wes Williams commented on GEODE-2268:
-

I think it simpler to keep the jars on the file system because it is a visual 
aid to inspect the cluster externally without having to log into gfsh and 
gfsh>deploy jar. Seeing the deployed jars helps when validating deployments and 
things are not right, for instance, when one member has the jar but another 
does not, etc. Placing them internally is arguably not simpler.

> Store jar bytes in cluster configuration region
> ---
>
> Key: GEODE-2268
> URL: https://issues.apache.org/jira/browse/GEODE-2268
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>
> Currently xml and properties are stored in an internal cluster configuration 
> region.  However, for jar files only the name is stored in this region, while 
> the jar bytes are stored in the filesystem of each locator.  We should 
> simplify things by storing the jar bytes in the same internal region.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: Geode-nightly #708

[Apache Jenkins Server]

See 

Changes:

[bschuchardt] GEODE-2155 Auto-reconnect fails with NPE

[abaker] GEODE-2016: change compile dependency to testCompile

[abaker] GEODE-1657 Remove silly ^M characters

--
[...truncated 699 lines...]
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assemble
:geode-web:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-web:processTestResources UP-TO-DATE
:geode-web:testClasses
:geode-web:checkMissedTests
:geode-web:spotlessJavaCheck
:geode-web:spotlessCheck
:geode-web:test
:geode-web:check
:geode-web:build
:geode-web:distributedTest
:geode-web:flakyTest
:geode-web:integrationTest
:geode-web-api:assemble
:geode-web-api:compileTestJava UP-TO-DATE
:geode-web-api:processTestResources UP-TO-DATE
:geode-web-api:testClasses UP-TO-DATE
:geode-web-api:checkMissedTests UP-TO-DATE
:geode-web-api:spotlessJavaCheck
:geode-web-api:spotlessCheck
:geode-web-api:test UP-TO-DATE
:geode-web-api:check
:geode-web-api:build
:geode-web-api:distributedTest UP-TO-DATE
:geode-web-api:flakyTest UP-TO-DATE
:geode-web-api:integrationTest UP-TO-DATE
:combineReports
All test reports at 

Re: copy files to servers

[Anthony Baker]

I think there are lots of great OS orchestration and automation tools.  I’m not 
sure I understand the need for `gfsh cp`.  If I could easily grab the member 
hostnames from `gfsh list members` and pipe them into mpssh (for example) that 
would do the job.

I *do* like the idea of an improved `gfsh deploy` that supports hot deploy and 
reconfiguration.

Anthony

> On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar  wrote:
> 
> Some application may need to copy files to all the servers. These files
> could either be data files or they could be configuration files needed by
> the application or they could be jar files (that don't have functions but
> have say, spring data geode jar files) that need to be on the server's
> classpath.
> We could accomplish this by enhancing the current gfsh "deploy" command to
> accept any kind of file and write it to the servers file system OR create a
> new gfsh "copy" command to copy any arbitrary file to the servers.
> I would personally like to repurpose the deploy command but would like to
> hear the community's opinion.
> 
> Thanks!

Re: Review Request 55236: GEODE-2271 Reduce pdx type id generation for string fields in JSON

[Udo Kohlmeyer]

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




geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java 
(lines 881 - 885)


How does this affect the "rest" of the system and the processing of PDX? 
Have we now impacted performance?



geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java (line 
263)


Maybe we need a test that confirms that we will only generate 2 type 
definitions. One where the field exists and one where the field does not exist


- Udo Kohlmeyer


On Jan. 5, 2017, 11:14 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55236/
> ---
> 
> (Updated Jan. 5, 2017, 11:14 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2271 JSOnFormatter can generate three pdxTypeId for one json field.
> 
> JSON field can have 3 values(fieldValue, NULL, fieldNotExist), this
> causes 3 pdxTypeIds. To reuduce this we merged first two values in 
> one pdxType.
> 
> Added unit test for it
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java 
> 4ebc33d 
>   
> geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceHelper.java
>  e957cd6 
>   geode-core/src/test/java/org/apache/geode/pdx/Employee.java cfb46b5 
>   geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java 
> 979da13 
>   geode-core/src/test/java/org/apache/geode/pdx/PdxStringJUnitTest.java 
> c072e14 
>   
> geode-core/src/test/java/org/apache/geode/pdx/TestObjectForJSONFormatter.java 
> ca0abc3 
> 
> Diff: https://reviews.apache.org/r/55236/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: copy files to servers

[Jacob Barrett]

Agree with Anthony. A copy command would either duplicate what deploy does
by only putting files within as specific location in the server's directory
or creating a security nightmare if allowed to write anywhere on the host.


On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker  wrote:

> I think there are lots of great OS orchestration and automation tools.
> I’m not sure I understand the need for `gfsh cp`.  If I could easily grab
> the member hostnames from `gfsh list members` and pipe them into mpssh (for
> example) that would do the job.
>
> I *do* like the idea of an improved `gfsh deploy` that supports hot deploy
> and reconfiguration.
>
> Anthony
>
> > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar 
> wrote:
> >
> > Some application may need to copy files to all the servers. These files
> > could either be data files or they could be configuration files needed by
> > the application or they could be jar files (that don't have functions but
> > have say, spring data geode jar files) that need to be on the server's
> > classpath.
> > We could accomplish this by enhancing the current gfsh "deploy" command
> to
> > accept any kind of file and write it to the servers file system OR
> create a
> > new gfsh "copy" command to copy any arbitrary file to the servers.
> > I would personally like to repurpose the deploy command but would like to
> > hear the community's opinion.
> >
> > Thanks!
>
>

Re: copy files to servers

[Michael Stolz]

So maybe a generic copy command is too insecure, I agree.
What we should do is think about exactly what files we think we are trying
to deploy.

   1. I believe that there is a need to deploy dependency jars into the
   system classpath.
   2. I believe that there is also a desire to be able to deploy Spring
   Data Geode xml configuration files.
   3. There is also an issue with attempting to deploy Spring Data Geode
   functions that we should try to work out.

Anything else that anyone is aware of?




--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett  wrote:

> Agree with Anthony. A copy command would either duplicate what deploy does
> by only putting files within as specific location in the server's directory
> or creating a security nightmare if allowed to write anywhere on the host.
>
>
> On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker  wrote:
>
> > I think there are lots of great OS orchestration and automation tools.
> > I’m not sure I understand the need for `gfsh cp`.  If I could easily grab
> > the member hostnames from `gfsh list members` and pipe them into mpssh
> (for
> > example) that would do the job.
> >
> > I *do* like the idea of an improved `gfsh deploy` that supports hot
> deploy
> > and reconfiguration.
> >
> > Anthony
> >
> > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar 
> > wrote:
> > >
> > > Some application may need to copy files to all the servers. These files
> > > could either be data files or they could be configuration files needed
> by
> > > the application or they could be jar files (that don't have functions
> but
> > > have say, spring data geode jar files) that need to be on the server's
> > > classpath.
> > > We could accomplish this by enhancing the current gfsh "deploy" command
> > to
> > > accept any kind of file and write it to the servers file system OR
> > create a
> > > new gfsh "copy" command to copy any arbitrary file to the servers.
> > > I would personally like to repurpose the deploy command but would like
> to
> > > hear the community's opinion.
> > >
> > > Thanks!
> >
> >
>

Re: copy files to servers

[Udo Kohlmeyer]

I think I can see the benefit of this feature.

If you have Geode running in the cloud, it is easier to have a single 
management tool that can copy resource files to all the servers within 
the cluster.


Although I would not see this a feature I'd promote, as it could really 
be abused, I believe it would work well for cloud environments.


--Udo


On 1/6/17 02:38, Swapnil Bawaskar wrote:

Some application may need to copy files to all the servers. These files
could either be data files or they could be configuration files needed by
the application or they could be jar files (that don't have functions but
have say, spring data geode jar files) that need to be on the server's
classpath.
We could accomplish this by enhancing the current gfsh "deploy" command to
accept any kind of file and write it to the servers file system OR create a
new gfsh "copy" command to copy any arbitrary file to the servers.
I would personally like to repurpose the deploy command but would like to
hear the community's opinion.

Thanks!

[jira] [Created] (GEODE-2275) CI Failure: ClearTXLockingDUnitTest.testPutWithClearDifferentVM

[Eric Shu (JIRA)]

Eric Shu created GEODE-2275:
---

 Summary: CI Failure: 
ClearTXLockingDUnitTest.testPutWithClearDifferentVM
 Key: GEODE-2275
 URL: https://issues.apache.org/jira/browse/GEODE-2275
 Project: Geode
  Issue Type: Bug
  Components: regions, transactions
Reporter: Eric Shu


org.apache.geode.internal.cache.ClearTXLockingDUnitTest > 
testPutWithClearDifferentVM FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1.run in VM 0 running 
on Host d7fcb695b430 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.runLockingTest(ClearTXLockingDUnitTest.java:206)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:170)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:115)

Caused by:
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1$$Lambda$21/402256214.run
 in VM 0 running on Host d7fcb695b430 with 4 VMs

Caused by:
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$24/1595591059.run
 in VM 1 running on Host d7fcb695b430 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.releaseRegionOperation(ClearTXLockingDUnitTest.java:324)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$100(ClearTXLockingDUnitTest.java:67)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest$CommitTestCallback.run(ClearTXLockingDUnitTest.java:408)
at 
org.apache.geode.internal.cache.TXState.applyChanges(TXState.java:796)
at 
org.apache.geode.internal.cache.TXState.commit(TXState.java:468)
at 
org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:254)
at 
org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:375)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.doPuts(ClearTXLockingDUnitTest.java:316)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:67)

Caused by:
java.lang.NullPointerException
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:324)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (GEODE-2276) CI Failure: ClearTXLockingDUnitTest.testPutWithClearDifferentVM

[Eric Shu (JIRA)]

Eric Shu created GEODE-2276:
---

 Summary: CI Failure: 
ClearTXLockingDUnitTest.testPutWithClearDifferentVM
 Key: GEODE-2276
 URL: https://issues.apache.org/jira/browse/GEODE-2276
 Project: Geode
  Issue Type: Bug
  Components: regions, transactions
Reporter: Eric Shu


org.apache.geode.internal.cache.ClearTXLockingDUnitTest > 
testPutWithClearDifferentVM FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1.run in VM 0 running 
on Host d7fcb695b430 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.runLockingTest(ClearTXLockingDUnitTest.java:206)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:170)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:115)

Caused by:
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1$$Lambda$21/402256214.run
 in VM 0 running on Host d7fcb695b430 with 4 VMs

Caused by:
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$24/1595591059.run
 in VM 1 running on Host d7fcb695b430 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.releaseRegionOperation(ClearTXLockingDUnitTest.java:324)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$100(ClearTXLockingDUnitTest.java:67)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest$CommitTestCallback.run(ClearTXLockingDUnitTest.java:408)
at 
org.apache.geode.internal.cache.TXState.applyChanges(TXState.java:796)
at 
org.apache.geode.internal.cache.TXState.commit(TXState.java:468)
at 
org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:254)
at 
org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:375)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.doPuts(ClearTXLockingDUnitTest.java:316)
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:67)

Caused by:
java.lang.NullPointerException
at 
org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:324)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 55272: GEDOE-2274: Add additional test cases for non colocated transactions

[Eric Shu]

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

Review request for geode, anilkumar gingade and Darrel Schneider.


Bugs: GEODE-2274
https://issues.apache.org/jira/browse/GEODE-2274


Repository: geode


Description
---

Test region entry operations with non colocated transactions fail with expected 
exception.


Diffs
-

  geode-core/src/test/java/org/apache/geode/disttx/PRDistTXDUnitTest.java 
1061cd5 
  
geode-core/src/test/java/org/apache/geode/disttx/PRDistTXWithVersionsDUnitTest.java
 34c28f4 
  
geode-core/src/test/java/org/apache/geode/internal/cache/execute/PRTransactionDUnitTest.java
 937059c 

Diff: https://reviews.apache.org/r/55272/diff/


Testing
---

precheckin.


Thanks,

Eric Shu

[jira] [Resolved] (GEODE-2276) CI Failure: ClearTXLockingDUnitTest.testPutWithClearDifferentVM

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-2276.
-
Resolution: Fixed

Closed as duplicate of GEODE:2275

> CI Failure: ClearTXLockingDUnitTest.testPutWithClearDifferentVM
> ---
>
> Key: GEODE-2276
> URL: https://issues.apache.org/jira/browse/GEODE-2276
> Project: Geode
>  Issue Type: Bug
>  Components: regions, transactions
>Reporter: Eric Shu
>
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest > 
> testPutWithClearDifferentVM FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1.run in VM 0 running 
> on Host d7fcb695b430 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.runLockingTest(ClearTXLockingDUnitTest.java:206)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:170)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:115)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1$$Lambda$21/402256214.run
>  in VM 0 running on Host d7fcb695b430 with 4 VMs
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$24/1595591059.run
>  in VM 1 running on Host d7fcb695b430 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.releaseRegionOperation(ClearTXLockingDUnitTest.java:324)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$100(ClearTXLockingDUnitTest.java:67)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$CommitTestCallback.run(ClearTXLockingDUnitTest.java:408)
> at 
> org.apache.geode.internal.cache.TXState.applyChanges(TXState.java:796)
> at 
> org.apache.geode.internal.cache.TXState.commit(TXState.java:468)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:254)
> at 
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:375)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.doPuts(ClearTXLockingDUnitTest.java:316)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:67)
> Caused by:
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:324)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2275) CI Failure: ClearTXLockingDUnitTest.testPutWithClearDifferentVM

[Eric Shu (JIRA)]

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

Eric Shu updated GEODE-2275:

Labels: ci flaky  (was: )

> CI Failure: ClearTXLockingDUnitTest.testPutWithClearDifferentVM
> ---
>
> Key: GEODE-2275
> URL: https://issues.apache.org/jira/browse/GEODE-2275
> Project: Geode
>  Issue Type: Bug
>  Components: regions, transactions
>Reporter: Eric Shu
>  Labels: ci, flaky
>
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest > 
> testPutWithClearDifferentVM FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1.run in VM 0 running 
> on Host d7fcb695b430 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.runLockingTest(ClearTXLockingDUnitTest.java:206)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.performTestAndCheckResults(ClearTXLockingDUnitTest.java:170)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.testPutWithClearDifferentVM(ClearTXLockingDUnitTest.java:115)
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$1$$Lambda$21/402256214.run
>  in VM 0 running on Host d7fcb695b430 with 4 VMs
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$$Lambda$24/1595591059.run
>  in VM 1 running on Host d7fcb695b430 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.releaseRegionOperation(ClearTXLockingDUnitTest.java:324)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$100(ClearTXLockingDUnitTest.java:67)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest$CommitTestCallback.run(ClearTXLockingDUnitTest.java:408)
> at 
> org.apache.geode.internal.cache.TXState.applyChanges(TXState.java:796)
> at 
> org.apache.geode.internal.cache.TXState.commit(TXState.java:468)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:254)
> at 
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:375)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.doPuts(ClearTXLockingDUnitTest.java:316)
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.access$000(ClearTXLockingDUnitTest.java:67)
> Caused by:
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.ClearTXLockingDUnitTest.lambda$releaseRegionOperation$b6506259$1(ClearTXLockingDUnitTest.java:324)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: copy files to servers

[Jens Deppe]

Got to chime in here and +1 on what Anthony's and Jake's sentiments are.

Let's be *very* careful and try to understand what users are trying to
achieve.

If we're providing a 'gfsh cp' option that then requires further
intervention to actually achieve what the user wants (i.e. server restart
or whatever is required to now use the new files) then we're nowhere better
off than we are now. 'gfsh cp' seems like a targeted solution.

I'd prefer to see us do a better job of classloading and have that be
clearly specified. Someone mentioned that Geode isn't a container but I
would argue that as soon as we can accept and run somebody else's code
we're a container and should provide facilities to dynamically manage the
lifecycle of that code.

--Jens

On Fri, Jan 6, 2017 at 8:31 AM, Udo Kohlmeyer  wrote:

> I think I can see the benefit of this feature.
>
> If you have Geode running in the cloud, it is easier to have a single
> management tool that can copy resource files to all the servers within the
> cluster.
>
> Although I would not see this a feature I'd promote, as it could really be
> abused, I believe it would work well for cloud environments.
>
> --Udo
>
>
>
> On 1/6/17 02:38, Swapnil Bawaskar wrote:
>
>> Some application may need to copy files to all the servers. These files
>> could either be data files or they could be configuration files needed by
>> the application or they could be jar files (that don't have functions but
>> have say, spring data geode jar files) that need to be on the server's
>> classpath.
>> We could accomplish this by enhancing the current gfsh "deploy" command to
>> accept any kind of file and write it to the servers file system OR create
>> a
>> new gfsh "copy" command to copy any arbitrary file to the servers.
>> I would personally like to repurpose the deploy command but would like to
>> hear the community's opinion.
>>
>> Thanks!
>>
>>
>

[jira] [Created] (GEODE-2277) client cache fails to deserialize a PdxInstance due to InternalGemFireError

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2277:
---

 Summary: client cache fails to deserialize a PdxInstance due to 
InternalGemFireError
 Key: GEODE-2277
 URL: https://issues.apache.org/jira/browse/GEODE-2277
 Project: Geode
  Issue Type: Bug
  Components: serialization
Reporter: Bruce Schuchardt


In a WAN configuration using partitioned regions and parallel gateways a client 
in one of the clusters failed to deserialize a PdxInstance received from one of 
the other clusters.

{noformat}
[error 2016/12/09 22:59:00.930 EST 
edgegemfire_4_2_rs-intTest-rhel7-2016-12-09-21-33-28-client-12_28424 :1032
 port 29079> tid=0x33] Exception occurred in CacheListener
org.apache.geode.InternalGemFireError: Unable to determine PDXType for id 
64307729
at 
org.apache.geode.pdx.internal.ClientTypeRegistration.returnCorrectExceptionForFailure(ClientTypeRegistration.java:305)
at 
org.apache.geode.pdx.internal.ClientTypeRegistration.getEnumById(ClientTypeRegistration.java:208)
at 
org.apache.geode.pdx.internal.LonerTypeRegistration.getEnumById(LonerTypeRegistration.java:133)
at 
org.apache.geode.pdx.internal.TypeRegistry.getEnumInfoById(TypeRegistry.java:430)
at 
org.apache.geode.pdx.internal.TypeRegistry.getEnumById(TypeRegistry.java:406)
at 
org.apache.geode.internal.InternalDataSerializer.readPdxEnum(InternalDataSerializer.java:2258)
at 
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:3007)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2897)
at 
org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:251)
at 
org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:96)
at 
org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:332)
at 
org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:325)
at util.VersionedValueHolder.myFromData(VersionedValueHolder.java:610)
at 
util.PdxVersionedValueHolder.fromData(PdxVersionedValueHolder.java:117)
at 
org.apache.geode.pdx.internal.PdxReaderImpl.basicGetObject(PdxReaderImpl.java:737)
at 
org.apache.geode.pdx.internal.PdxReaderImpl.getObject(PdxReaderImpl.java:682)
at 
org.apache.geode.internal.InternalDataSerializer.readPdxSerializable(InternalDataSerializer.java:3218)
at 
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:3005)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2897)
at 
org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:90)
at 
org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1891)
at 
org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1884)
at 
org.apache.geode.internal.offheap.OffHeapStoredObject.getDeserializedValue(OffHeapStoredObject.java:447)
at 
org.apache.geode.internal.cache.EntryEventImpl.lambda$getNewValue$1(EntryEventImpl.java:951)
at 
org.apache.geode.internal.cache.EntryEventImpl.callWithOffHeapLock(EntryEventImpl.java:980)
at 
org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:946)
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2277) client cache fails to deserialize a PdxInstance due to InternalGemFireError

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2277:


Commit fb36df21972708fe41fea5ffc72f36932e604121 in geode's branch 
refs/heads/feature/GEODE-2277 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fb36df2 ]

GEODE-2277: reworked PDX type/enum logging to help identify source of issue


> client cache fails to deserialize a PdxInstance due to InternalGemFireError
> ---
>
> Key: GEODE-2277
> URL: https://issues.apache.org/jira/browse/GEODE-2277
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Bruce Schuchardt
>
> In a WAN configuration using partitioned regions and parallel gateways a 
> client in one of the clusters failed to deserialize a PdxInstance received 
> from one of the other clusters.
> {noformat}
> [error 2016/12/09 22:59:00.930 EST 
> edgegemfire_4_2_rs-intTest-rhel7-2016-12-09-21-33-28-client-12_28424  Client Updater Thread  on 
> rs-intTest-rhel7-2016-12-09-21-33-28-client-12(bridgegemfire_4_4_rs-intTest-rhel7-2016-12-09-21-33-28-client-12_28256:28256):1032
>  port 29079> tid=0x33] Exception occurred in CacheListener
> org.apache.geode.InternalGemFireError: Unable to determine PDXType for id 
> 64307729
> at 
> org.apache.geode.pdx.internal.ClientTypeRegistration.returnCorrectExceptionForFailure(ClientTypeRegistration.java:305)
> at 
> org.apache.geode.pdx.internal.ClientTypeRegistration.getEnumById(ClientTypeRegistration.java:208)
> at 
> org.apache.geode.pdx.internal.LonerTypeRegistration.getEnumById(LonerTypeRegistration.java:133)
> at 
> org.apache.geode.pdx.internal.TypeRegistry.getEnumInfoById(TypeRegistry.java:430)
> at 
> org.apache.geode.pdx.internal.TypeRegistry.getEnumById(TypeRegistry.java:406)
> at 
> org.apache.geode.internal.InternalDataSerializer.readPdxEnum(InternalDataSerializer.java:2258)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:3007)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2897)
> at 
> org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:251)
> at 
> org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:96)
> at 
> org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:332)
> at 
> org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:325)
> at util.VersionedValueHolder.myFromData(VersionedValueHolder.java:610)
> at 
> util.PdxVersionedValueHolder.fromData(PdxVersionedValueHolder.java:117)
> at 
> org.apache.geode.pdx.internal.PdxReaderImpl.basicGetObject(PdxReaderImpl.java:737)
> at 
> org.apache.geode.pdx.internal.PdxReaderImpl.getObject(PdxReaderImpl.java:682)
> at 
> org.apache.geode.internal.InternalDataSerializer.readPdxSerializable(InternalDataSerializer.java:3218)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:3005)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2897)
> at 
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:90)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1891)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1884)
> at 
> org.apache.geode.internal.offheap.OffHeapStoredObject.getDeserializedValue(OffHeapStoredObject.java:447)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.lambda$getNewValue$1(EntryEventImpl.java:951)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.callWithOffHeapLock(EntryEventImpl.java:980)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:946)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: copy files to servers

[Real Wes]

Here’s a use-case I’m dealing with right now:  A single cluster supporting 
multiple applications (i.e. a multi-tenant cluster). One new application wants 
to do Spring http session replication. This requires placing 3 Spring jars onto 
the start server —classpath=$SPRING_JARS:… It requires a cluster bounce.

Would be really nice to do this without bouncing the entire cluster. May need 
to do so anyway since this is a Java restriction, but at least you see  a real 
use-case.

Wes

> On Jan 6, 2017, at 12:11 PM, Jens Deppe  wrote:
> 
> Got to chime in here and +1 on what Anthony's and Jake's sentiments are.
> 
> Let's be *very* careful and try to understand what users are trying to
> achieve.
> 
> If we're providing a 'gfsh cp' option that then requires further
> intervention to actually achieve what the user wants (i.e. server restart
> or whatever is required to now use the new files) then we're nowhere better
> off than we are now. 'gfsh cp' seems like a targeted solution.
> 
> I'd prefer to see us do a better job of classloading and have that be
> clearly specified. Someone mentioned that Geode isn't a container but I
> would argue that as soon as we can accept and run somebody else's code
> we're a container and should provide facilities to dynamically manage the
> lifecycle of that code.
> 
> --Jens
> 
> On Fri, Jan 6, 2017 at 8:31 AM, Udo Kohlmeyer  wrote:
> 
>> I think I can see the benefit of this feature.
>> 
>> If you have Geode running in the cloud, it is easier to have a single
>> management tool that can copy resource files to all the servers within the
>> cluster.
>> 
>> Although I would not see this a feature I'd promote, as it could really be
>> abused, I believe it would work well for cloud environments.
>> 
>> --Udo
>> 
>> 
>> 
>> On 1/6/17 02:38, Swapnil Bawaskar wrote:
>> 
>>> Some application may need to copy files to all the servers. These files
>>> could either be data files or they could be configuration files needed by
>>> the application or they could be jar files (that don't have functions but
>>> have say, spring data geode jar files) that need to be on the server's
>>> classpath.
>>> We could accomplish this by enhancing the current gfsh "deploy" command to
>>> accept any kind of file and write it to the servers file system OR create
>>> a
>>> new gfsh "copy" command to copy any arbitrary file to the servers.
>>> I would personally like to repurpose the deploy command but would like to
>>> hear the community's opinion.
>>> 
>>> Thanks!
>>> 
>>> 
>> 

Re: copy files to servers

[Kirk Lund]

Even though Apache Geode is accepting jars containing Geode callback
implementations (Functions, CacheListener, etc), it's NOT a container or
application server. You can WANT it to be a container or EXPECT it to be a
container but it's not ;) This would require Apache Geode becoming an
application server. To become an application server would require extensive
rearchitecting to introduce a complex classloading hierarchy for
application isolation. Whether you want this functionality or not, the
unfortunate truth is it cannot be done in a few weeks by a few developers.
If it's important then it becomes one of the few new features that can be
added to something like Geode in a given year. It would be better to find
other open-source containers such as Apache Felix and install Apache Geode
in it and then use Felix as the container. We could theoretically turn
Apache Geode into a project that depends on Apache Felix (or another
container project) such that starting an Apache Geode Locator or Server
actually starts up an Apache Felix process with Geode running inside it and
available for applications that are then deployed into Felix.


On Fri, Jan 6, 2017 at 9:44 AM, Real Wes  wrote:

> Here’s a use-case I’m dealing with right now:  A single cluster supporting
> multiple applications (i.e. a multi-tenant cluster). One new application
> wants to do Spring http session replication. This requires placing 3 Spring
> jars onto the start server —classpath=$SPRING_JARS:… It requires a cluster
> bounce.
>
> Would be really nice to do this without bouncing the entire cluster. May
> need to do so anyway since this is a Java restriction, but at least you
> see  a real use-case.
>
> Wes
>
> > On Jan 6, 2017, at 12:11 PM, Jens Deppe  wrote:
> >
> > Got to chime in here and +1 on what Anthony's and Jake's sentiments are.
> >
> > Let's be *very* careful and try to understand what users are trying to
> > achieve.
> >
> > If we're providing a 'gfsh cp' option that then requires further
> > intervention to actually achieve what the user wants (i.e. server restart
> > or whatever is required to now use the new files) then we're nowhere
> better
> > off than we are now. 'gfsh cp' seems like a targeted solution.
> >
> > I'd prefer to see us do a better job of classloading and have that be
> > clearly specified. Someone mentioned that Geode isn't a container but I
> > would argue that as soon as we can accept and run somebody else's code
> > we're a container and should provide facilities to dynamically manage the
> > lifecycle of that code.
> >
> > --Jens
> >
> > On Fri, Jan 6, 2017 at 8:31 AM, Udo Kohlmeyer 
> wrote:
> >
> >> I think I can see the benefit of this feature.
> >>
> >> If you have Geode running in the cloud, it is easier to have a single
> >> management tool that can copy resource files to all the servers within
> the
> >> cluster.
> >>
> >> Although I would not see this a feature I'd promote, as it could really
> be
> >> abused, I believe it would work well for cloud environments.
> >>
> >> --Udo
> >>
> >>
> >>
> >> On 1/6/17 02:38, Swapnil Bawaskar wrote:
> >>
> >>> Some application may need to copy files to all the servers. These files
> >>> could either be data files or they could be configuration files needed
> by
> >>> the application or they could be jar files (that don't have functions
> but
> >>> have say, spring data geode jar files) that need to be on the server's
> >>> classpath.
> >>> We could accomplish this by enhancing the current gfsh "deploy"
> command to
> >>> accept any kind of file and write it to the servers file system OR
> create
> >>> a
> >>> new gfsh "copy" command to copy any arbitrary file to the servers.
> >>> I would personally like to repurpose the deploy command but would like
> to
> >>> hear the community's opinion.
> >>>
> >>> Thanks!
> >>>
> >>>
> >>
>
>

[GitHub] geode issue #305: [GEODE-1923] Fix a test race condition.

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/305
  
@kohlmu-pivotal Could you merge this for me please?


---
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-1923) CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch

[ASF GitHub Bot (JIRA)]

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

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

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/305
  
@kohlmu-pivotal Could you merge this for me please?


> CI Failure: FixedPRSinglehopDUnitTest.test_FPAmetadataFetch
> ---
>
> Key: GEODE-1923
> URL: https://issues.apache.org/jira/browse/GEODE-1923
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Eric Shu
>Assignee: Bruce Schuchardt
>  Labels: ci, flaky
>
> java.lang.AssertionError: expected: but was:
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.updateIntoSinglePR(FixedPRSinglehopDUnitTest.java:765)
>   at 
> org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.test_FPAmetadataFetch(FixedPRSinglehopDUnitTest.java:339)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.int

[jira] [Commented] (GEODE-2277) client cache fails to deserialize a PdxInstance due to InternalGemFireError

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2277:


Commit 3cf6d525704de6d79721583a7fb41a566311918f in geode's branch 
refs/heads/feature/GEODE-2277 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3cf6d52 ]

GEODE-2277 logging tweaks

Added beforeCreate() logging for PdxTypes.  The old logging was
incorrectly in beforeUpdate().


> client cache fails to deserialize a PdxInstance due to InternalGemFireError
> ---
>
> Key: GEODE-2277
> URL: https://issues.apache.org/jira/browse/GEODE-2277
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Bruce Schuchardt
>
> In a WAN configuration using partitioned regions and parallel gateways a 
> client in one of the clusters failed to deserialize a PdxInstance received 
> from one of the other clusters.
> {noformat}
> [error 2016/12/09 22:59:00.930 EST 
> edgegemfire_4_2_rs-intTest-rhel7-2016-12-09-21-33-28-client-12_28424  Client Updater Thread  on 
> rs-intTest-rhel7-2016-12-09-21-33-28-client-12(bridgegemfire_4_4_rs-intTest-rhel7-2016-12-09-21-33-28-client-12_28256:28256):1032
>  port 29079> tid=0x33] Exception occurred in CacheListener
> org.apache.geode.InternalGemFireError: Unable to determine PDXType for id 
> 64307729
> at 
> org.apache.geode.pdx.internal.ClientTypeRegistration.returnCorrectExceptionForFailure(ClientTypeRegistration.java:305)
> at 
> org.apache.geode.pdx.internal.ClientTypeRegistration.getEnumById(ClientTypeRegistration.java:208)
> at 
> org.apache.geode.pdx.internal.LonerTypeRegistration.getEnumById(LonerTypeRegistration.java:133)
> at 
> org.apache.geode.pdx.internal.TypeRegistry.getEnumInfoById(TypeRegistry.java:430)
> at 
> org.apache.geode.pdx.internal.TypeRegistry.getEnumById(TypeRegistry.java:406)
> at 
> org.apache.geode.internal.InternalDataSerializer.readPdxEnum(InternalDataSerializer.java:2258)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:3007)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2897)
> at 
> org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:251)
> at 
> org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:96)
> at 
> org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:332)
> at 
> org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:325)
> at util.VersionedValueHolder.myFromData(VersionedValueHolder.java:610)
> at 
> util.PdxVersionedValueHolder.fromData(PdxVersionedValueHolder.java:117)
> at 
> org.apache.geode.pdx.internal.PdxReaderImpl.basicGetObject(PdxReaderImpl.java:737)
> at 
> org.apache.geode.pdx.internal.PdxReaderImpl.getObject(PdxReaderImpl.java:682)
> at 
> org.apache.geode.internal.InternalDataSerializer.readPdxSerializable(InternalDataSerializer.java:3218)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:3005)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2897)
> at 
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:90)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1891)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1884)
> at 
> org.apache.geode.internal.offheap.OffHeapStoredObject.getDeserializedValue(OffHeapStoredObject.java:447)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.lambda$getNewValue$1(EntryEventImpl.java:951)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.callWithOffHeapLock(EntryEventImpl.java:980)
> at 
> org.apache.geode.internal.cache.EntryEventImpl.getNewValue(EntryEventImpl.java:946)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-224) Geode Spark connector parser is not processing type casting properly

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-224.
-
Resolution: Fixed

> Geode Spark connector parser is not processing type casting properly
> 
>
> Key: GEODE-224
> URL: https://issues.apache.org/jira/browse/GEODE-224
> Project: Geode
>  Issue Type: Bug
>  Components: extensions
>Reporter: William Markito Oliveira
>Assignee: Kai Jiang
>Priority: Minor
>  Labels: gsoc2016
> Fix For: 1.1.0
>
>
> Using GFSH a user can execute queries casting the data types but that's not 
> working using the geode-spark-connector. 
> {code}
> scala> sqlContext.gemfireOQL("SELECT (Double)t.ema, (Double)t.future_ema, 
> (Double)t.close, t.entryTimestamp FROM /TechIndicators t ");
> java.lang.RuntimeException: No result when parsing failed
> at scala.sys.package$.error(package.scala:27)
> at scala.util.parsing.combinator.Parsers$NoSuccess.get(Parsers.scala:181)
> at scala.util.parsing.combinator.Parsers$NoSuccess.get(Parsers.scala:167)
> at 
> io.pivotal.gemfire.spark.connector.internal.oql.QueryRDD.getRegionPathFromQuery(QueryRDD.scala:56)
> at 
> io.pivotal.gemfire.spark.connector.internal.oql.QueryRDD.getPartitions(QueryRDD.scala:24)
> at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:219)
> at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:217)
> at scala.Option.getOrElse(Option.scala:120)
> at org.apache.spark.rdd.RDD.partitions(RDD.scala:217)
> at org.apache.spark.rdd.RDD.take(RDD.scala:1156)
> at org.apache.spark.rdd.RDD.first(RDD.scala:1189)
> at 
> io.pivotal.gemfire.spark.connector.internal.oql.SchemaBuilder.toSparkSchema(SchemaBuilder.scala:30)
> at 
> io.pivotal.gemfire.spark.connector.internal.oql.OQLRelation.schema(RDDConverter.scala:13)
> at 
> org.apache.spark.sql.sources.LogicalRelation.(LogicalRelation.scala:30)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: The next release (v1.1.0)

[Anthony Baker]

Our last release was on October 25.  I think we’re past due for another one!  
We’ve had lots of great contributions since 1.0.0-incubating and now that we’re 
are a top-level project we can drop the “-incubating” qualifier.

I reviewed our open JIRA issues and would like to include the following in the 
release:

GEODE-2142 - JSON license incompatibility
We can update the NOTICE files and leave the JSON dependency alone (as 
long as we do another release before April 30).

GEODE-1965 - backwards compatibility tests
I’d like to make sure we haven’t broken anything since our last release.

GEODE-2031 - versioned documentation
Seems relatively straightforward?

The remaining issues that are tagged with v1.1.0 [1] could be pushed to a 
following release IMO.  Thoughts?

Regarding the release manager, I can do the dirty work if no one else wants to 
volunteer :-)

Anthony

[1] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20GEODE%20AND%20fixVersion%20%3D%201.1.0%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

> On Nov 21, 2016, at 9:26 AM, Anthony Baker  wrote:
> 
> Now that graduation is done (!!), we need to organize our next release.  I 
> propose we focus on completing the transition to TLP and cleaning up 
> “incubating" references.  The sequence would look something like this:
> 
> 1) Transition the git repo, mailing lists, etc.
> 2) Update incubating references in source, docs, website, wiki, …
> 3) Do a release.
> 
> Thoughts?
> 
> We need a release manager.  Any volunteers?
> 
> Also, we need to rename the JIRA version from 1.1.0-incubating to 1.1.0.  Can 
> someone with JIRA karma help?
> 
> Anthony
> 

Re: Review Request 55236: GEODE-2271 Reduce pdx type id generation for string fields in JSON

[Darrel Schneider]

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




geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java (line 
890)


The name of this method is a bit confusing.
It is an OBJECT field. You are checking if it contains a String.
A better name would be "getPdxStringFromObjectField".
You should javadoc that it will return null if the given field does not 
contain a String.
I think it would be even better if this method did the test 
"ft.getFieldType() == FieldType.STRING" instead of the caller doing it. Then 
the caller would just look like this:
  PdxString pdxString = getPdxStringFromObjectField(ft);
  if (pdxString != null) {
return pdxString;
  }
  return readField(field);



geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java (line 
900)


Get rid of this first "if". All you need is the condition on the "else if".



geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceHelper.java
 (line 66)


I think this change is confusing. PdxInstanceHelper has an add method for 
every type of pdx field. Wouldn't it be better to have the one caller of this 
method to instead call addObjectField instead of changing the meaning of 
addStringField?


- Darrel Schneider


On Jan. 5, 2017, 3:14 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55236/
> ---
> 
> (Updated Jan. 5, 2017, 3:14 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2271 JSOnFormatter can generate three pdxTypeId for one json field.
> 
> JSON field can have 3 values(fieldValue, NULL, fieldNotExist), this
> causes 3 pdxTypeIds. To reuduce this we merged first two values in 
> one pdxType.
> 
> Added unit test for it
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java 
> 4ebc33d 
>   
> geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceHelper.java
>  e957cd6 
>   geode-core/src/test/java/org/apache/geode/pdx/Employee.java cfb46b5 
>   geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java 
> 979da13 
>   geode-core/src/test/java/org/apache/geode/pdx/PdxStringJUnitTest.java 
> c072e14 
>   
> geode-core/src/test/java/org/apache/geode/pdx/TestObjectForJSONFormatter.java 
> ca0abc3 
> 
> Diff: https://reviews.apache.org/r/55236/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: copy files to servers

[John Blum]

The problem is always tricky when you are working with dependencies and
class loading.  It is a two part problem.

1.  First, you must acquire and deploy the dependencies an application will
need at runtime.

This can be achieved many different ways, such as by "copying" files to a
designated, well-known location, adding them to the classpath on startup,
or perhaps, you provide a meta-data file with dependency declarations like
Maven/Gradle the resolves the dependencies and adds to the classpath at
startup.

2. Then, you need to apply those dependencies, possible without bringing
down the server.

This is much more difficult to achieve, particularly since deploying and
possibly "updating" dependencies will possibly (and most likely) disrupt
the lifecycle of the (previously) deployed code.

I have said Geode/GemFire is not an application container, and it's not.
This extends well beyond classpath isolation too.

There is a sharp contrast between deploying Functions (equivalent to Stored
Procedures/Functions in a RDBMS), or other types of callbacks
(CacheListeners, Loader, Writers) and deploying and running, say, *Spring*
code in Geode/GemFire.  While the former can be done without bringing down
Geode/GemFire, the later is much more difficult since the *Spring*
ApplicationContext (aka a "container") must be, in effect, restarted.

This in-turn can have adverse affects on other the application
components/beans that may be defined within that (nested) context, which
have nothing to do with Geode/GemFire.  These components, may in turn
acquire and potentially use other system resources; think DataSources,
Files, Message Queues, etc.  Managing these sort of interactions is much
more complex and cannot happen effectively without proper lifecycle
events/messaging and scopes (e.g. singleton, prototype, session,
request/thread, etc) provided by the container.

The closet Geode/GemFire comes to messaging for the application components
is the ResourceEventsListener

[1]
and the corresponding ResourceEvent

[2] (which
has "interesting" to application components type events), neither which is
part of the public API.  Still, this is not enough as application
components would need an event hierarchy (for example

[3])
where it could fire it's own type of events as well.

It's not uncommon for some system/environments to be "scriptable", but that
is much different than application code that is managed by a container.

For these reasons, as well as others, I generally do not recommend users
use Geode/GemFire to bootstrap other application code, rather the inverse
is more sensible and more flexible as you migrate to other "managed"
environments, like PCF.

1 thing is for certain though, users are going to want the ability to
"manage" their application dependencies (i.e. upgrade, provide their own,
etc), which may also be required by the services (e.g. Geode/GemFire) their
applications consume in that managed environment.

-John

[1]
https://github.com/apache/geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/distributed/internal/ResourceEventsListener.java
[2]
https://github.com/apache/geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/distributed/internal/ResourceEvent.java
[3]
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/ApplicationEvent.html


On Fri, Jan 6, 2017 at 10:03 AM, Kirk Lund  wrote:

> Even though Apache Geode is accepting jars containing Geode callback
> implementations (Functions, CacheListener, etc), it's NOT a container or
> application server. You can WANT it to be a container or EXPECT it to be a
> container but it's not ;) This would require Apache Geode becoming an
> application server. To become an application server would require extensive
> rearchitecting to introduce a complex classloading hierarchy for
> application isolation. Whether you want this functionality or not, the
> unfortunate truth is it cannot be done in a few weeks by a few developers.
> If it's important then it becomes one of the few new features that can be
> added to something like Geode in a given year. It would be better to find
> other open-source containers such as Apache Felix and install Apache Geode
> in it and then use Felix as the container. We could theoretically turn
> Apache Geode into a project that depends on Apache Felix (or another
> container project) such that starting an Apache Geode Locator or Server
> actually starts up an Apache Felix process with Geode running inside it and
> available for applications that are then deployed into Feli

[jira] [Commented] (GEODE-1165) CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1165:


Commit a6d6d08fc6841d86e2e0cbd45ed43dfeb5affdcf in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a6d6d08 ]

GEODE-1165: move FlakyTest category to class for all tests


> CI failure: SharedConfigurationUsingDirDUnitTest tests are flaky
> 
>
> Key: GEODE-1165
> URL: https://issues.apache.org/jira/browse/GEODE-1165
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh, management, tests
>Affects Versions: 1.0.0-incubating
>Reporter: Jianxia Chen
>Assignee: Kirk Lund
>  Labels: CI, Flaky
>
> Several tests in SharedConfigurationUsingDirDUnitTest are flaky and fail 
> intermittently. One known cause is GEODE-2238 (one cause has been fixed and 
> committed). The timeout used by these tests is 15 seconds which is quite low 
> if a GC pause occurs.
> 1) GEODE-1165 includes BindException:
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.test.dunit.NamedRunnable.run in VM 1 running on Host 
> cc2-ub.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:303)
>   at 
> com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.startLocator(SharedConfigurationUsingDirDUnitTest.java:266)
>   at 
> com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest.updateClusterConfigDirWithTwoLocatorsNoRollingServerRestart(SharedConfigurationUsingDirDUnitTest.java:122)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org

[jira] [Created] (GEODE-2278) Creating a member without a lucene index before a member with a lucene index causes an NPE

[Dan Smith (JIRA)]

Dan Smith created GEODE-2278:


 Summary: Creating a member without a lucene index before a member 
with a lucene index causes an NPE
 Key: GEODE-2278
 URL: https://issues.apache.org/jira/browse/GEODE-2278
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Dan Smith


I hit this when I misconfigured my system and had a member without a lucene 
index started before I started a member with a lucene index

{noformat}
ava.lang.NullPointerException
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
org.apache.geode.internal.cache.LocalRegion.getCacheServiceProfile(LocalRegion.java:10696)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.checkCompatibility(CreateRegionProcessor.java:617)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:471)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
org.apache.geode.distributed.internal.DistributionManager$5$1.run(DistributionManager.java:917)
at Remote Member 
'172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
java.lang.Thread.run(Thread.java:745)
at 
org.apache.geode.distributed.internal.ReplyException.handleAsUnexpected(ReplyException.java:85)
at 
org.apache.geode.internal.cache.CreateRegionProcessor.initializeRegion(CreateRegionProcessor.java:136)
at 
org.apache.geode.internal.cache.PartitionedRegion.initPRInternals(PartitionedRegion.java:899)
at 
org.apache.geode.internal.cache.PartitionedRegion.initialize(PartitionedRegion.java:1058)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3299)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3194)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3182)
at hydra.RegionHelper.createRegion(RegionHelper.java:109)
at hydra.RegionHelper.createRegion(RegionHelper.java:79)
at hydra.RegionHelper.createRegion(RegionHelper.java:68)
at hydra.RegionHelper.createRegion(RegionHelper.java:50)
at util.CacheUtil.createRegion(CacheUtil.java:350)
at parReg.ParRegTest.HA_reinitializeRegion(ParRegTest.java:775)
at 
parReg.ParRegTest.HydraTask_HA_reinitializeDataStore(ParRegTest.java:544)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.execute(MethExecutor.java:182)
at hydra.MethExecutor.execute(MethExecutor.java:150)
at hydra.TestTask.execute(TestTask.java:192)
at hydra.RemoteTestModule$1.run(RemoteTestModule.java:2
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2278) Creating a member without a lucene index before a member with a lucene index causes an NPE

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-2278:


Assignee: Dan Smith

> Creating a member without a lucene index before a member with a lucene index 
> causes an NPE
> --
>
> Key: GEODE-2278
> URL: https://issues.apache.org/jira/browse/GEODE-2278
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> I hit this when I misconfigured my system and had a member without a lucene 
> index started before I started a member with a lucene index
> {noformat}
> ava.lang.NullPointerException
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> org.apache.geode.internal.cache.LocalRegion.getCacheServiceProfile(LocalRegion.java:10696)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.checkCompatibility(CreateRegionProcessor.java:617)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:471)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> org.apache.geode.distributed.internal.DistributionManager$5$1.run(DistributionManager.java:917)
>   at Remote Member 
> '172.16.115.241(accessorgemfire1_dsmith-virtual_80275:80275):1026' in 
> java.lang.Thread.run(Thread.java:745)
>   at 
> org.apache.geode.distributed.internal.ReplyException.handleAsUnexpected(ReplyException.java:85)
>   at 
> org.apache.geode.internal.cache.CreateRegionProcessor.initializeRegion(CreateRegionProcessor.java:136)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.initPRInternals(PartitionedRegion.java:899)
>   at 
> org.apache.geode.internal.cache.PartitionedRegion.initialize(PartitionedRegion.java:1058)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3299)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3194)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3182)
>   at hydra.RegionHelper.createRegion(RegionHelper.java:109)
>   at hydra.RegionHelper.createRegion(RegionHelper.java:79)
>   at hydra.RegionHelper.createRegion(RegionHelper.java:68)
>   at hydra.RegionHelper.createRegion(RegionHelper.java:50)
>   at util.CacheUtil.createRegion(CacheUtil.java:350)
>   at parReg.ParRegTest.HA_reinitializeRegion(ParRegTest.java:775)
>   at 
> parReg.ParRegTest.HydraTask_HA_reinitializeDataStore(ParRegTest.java:544)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at hydra.MethExecutor.execute(MethExecutor.java:182)
>   at hydra.MethExecutor.execute(MethExecutor.java:150)
>   at hydra.TestTask.execute(TestTask.java:192)
>   at hydra.RemoteTestModule$1.run(RemoteTestModule.java:2
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 55275: GEODE-2278 - Fix an NPE with inconsistent lucene indexes

[Dan Smith]

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

Review request for geode and Barry Oglesby.


Repository: geode


Description
---

If a member without a lucene index is created first, we should throw a
reasonable error rather than an NPE.


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
1343395da972ac5ef07feb424626840b7aea2e99 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneIndexCreationDUnitTest.java
 7e50636eaed9bc277f6b25c163695a7c78451610 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/test/LuceneTestUtilities.java
 cb28e88913e9424db075a1b5cf15f4ad89921817 

Diff: https://reviews.apache.org/r/55275/diff/


Testing
---


Thanks,

Dan Smith

[jira] [Assigned] (GEODE-2246) Invalid class cast in function execution

[Michael Dodge (JIRA)]

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

Michael Dodge reassigned GEODE-2246:


Assignee: Michael Dodge

> Invalid class cast in function execution
> 
>
> Key: GEODE-2246
> URL: https://issues.apache.org/jira/browse/GEODE-2246
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> In some situations (e.g., running a certain version of the native client 
> quickstarts) a ClassCastException is thrown inside ExecuteFunction66.run() at 
> line 391 of ExecuteFunction66.java:
> final DistributionManager newDM = (DistributionManager) dm;
> The variable dm is an instance of the interface 
> org.apache.geode.distributed.internal.DM. The class 
> org.apache.geode.distributed.internal.DistributionManager implements DM but 
> not all implementers of DM extend DistributionManager, e.g., 
> org.apache.geode.distributed.internal.LonerDistributionManager.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (GEODE-2279) Events may linger in HARegionQueue

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-2279:
--

 Summary: Events may linger in HARegionQueue
 Key: GEODE-2279
 URL: https://issues.apache.org/jira/browse/GEODE-2279
 Project: Geode
  Issue Type: Bug
  Components: client queues
Reporter: Jason Huynh


In HARegionQueue, removal of ack'd events is only done after dispatching a 
message.  If there are no more events to dispatch to a client, any ack'd 
messages that were received by the server, after the last dispatch, will linger 
in the queue.  This can lead to confusion with stats.

The secondaries themselves would be cleaned up by the QRM thread and does not 
have this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2279) Events may linger in HARegionQueue

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-2279:
--

Assignee: Jason Huynh

> Events may linger in HARegionQueue
> --
>
> Key: GEODE-2279
> URL: https://issues.apache.org/jira/browse/GEODE-2279
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> In HARegionQueue, removal of ack'd events is only done after dispatching a 
> message.  If there are no more events to dispatch to a client, any ack'd 
> messages that were received by the server, after the last dispatch, will 
> linger in the queue.  This can lead to confusion with stats.
> The secondaries themselves would be cleaned up by the QRM thread and does not 
> have this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: copy files to servers

[Kirk Lund]

With appropriate constraints, a copy file type command could be secure.

1) don't use Apache Geode without security AND make the command require
authorization permissions
2) limit the target directory to a directory under the working directory of
the remote server
3) rename it to "deploy resource" so people don't expect it to copy to an
arbitrary target directory on the remote machine

Back to "deploy jar":

The deploy command is only for deploying Apache Geode callbacks (Function,
CacheListener, etc). "deploy resource" such Spring jars or Spring xml files
or anything similar does not overlap with "deploy jar". There is continued
confusion over what "deploy jar" is or does. I propose we rename it to
"deploy functions" or "deploy callbacks" or something along those lines to
end the confusion.

On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:

> So maybe a generic copy command is too insecure, I agree.
> What we should do is think about exactly what files we think we are trying
> to deploy.
>
>1. I believe that there is a need to deploy dependency jars into the
>system classpath.
>2. I believe that there is also a desire to be able to deploy Spring
>Data Geode xml configuration files.
>3. There is also an issue with attempting to deploy Spring Data Geode
>functions that we should try to work out.
>
> Anything else that anyone is aware of?
>
>
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: 631-835-4771
>
> On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
> wrote:
>
> > Agree with Anthony. A copy command would either duplicate what deploy
> does
> > by only putting files within as specific location in the server's
> directory
> > or creating a security nightmare if allowed to write anywhere on the
> host.
> >
> >
> > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker  wrote:
> >
> > > I think there are lots of great OS orchestration and automation tools.
> > > I’m not sure I understand the need for `gfsh cp`.  If I could easily
> grab
> > > the member hostnames from `gfsh list members` and pipe them into mpssh
> > (for
> > > example) that would do the job.
> > >
> > > I *do* like the idea of an improved `gfsh deploy` that supports hot
> > deploy
> > > and reconfiguration.
> > >
> > > Anthony
> > >
> > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar 
> > > wrote:
> > > >
> > > > Some application may need to copy files to all the servers. These
> files
> > > > could either be data files or they could be configuration files
> needed
> > by
> > > > the application or they could be jar files (that don't have functions
> > but
> > > > have say, spring data geode jar files) that need to be on the
> server's
> > > > classpath.
> > > > We could accomplish this by enhancing the current gfsh "deploy"
> command
> > > to
> > > > accept any kind of file and write it to the servers file system OR
> > > create a
> > > > new gfsh "copy" command to copy any arbitrary file to the servers.
> > > > I would personally like to repurpose the deploy command but would
> like
> > to
> > > > hear the community's opinion.
> > > >
> > > > Thanks!
> > >
> > >
> >
>

Re: copy files to servers

[John Blum]

How about...

* deploy function
* deploy cache-listener
* deploy cache-loader
* deploy cache-loader
* deploy resource (jar, xml, properties, etc)
* etc.

Might as was make it explicit.  For instance, I may have a JAR file I just
deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
etc but I only want to deploy functions.

Having 1 uber "deploy" command with many options gets cumbersome.

It is a simple matter to introduce multiple command but have those commands
share similar logic.  This would also enable different workflows for
different commands in a more non-convoluted, maintainable way.

These could be matched with corresponding `undeploy` commands.

Food for thought,

John



On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:

> With appropriate constraints, a copy file type command could be secure.
>
> 1) don't use Apache Geode without security AND make the command require
> authorization permissions
> 2) limit the target directory to a directory under the working directory of
> the remote server
> 3) rename it to "deploy resource" so people don't expect it to copy to an
> arbitrary target directory on the remote machine
>
> Back to "deploy jar":
>
> The deploy command is only for deploying Apache Geode callbacks (Function,
> CacheListener, etc). "deploy resource" such Spring jars or Spring xml files
> or anything similar does not overlap with "deploy jar". There is continued
> confusion over what "deploy jar" is or does. I propose we rename it to
> "deploy functions" or "deploy callbacks" or something along those lines to
> end the confusion.
>
> On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:
>
> > So maybe a generic copy command is too insecure, I agree.
> > What we should do is think about exactly what files we think we are
> trying
> > to deploy.
> >
> >1. I believe that there is a need to deploy dependency jars into the
> >system classpath.
> >2. I believe that there is also a desire to be able to deploy Spring
> >Data Geode xml configuration files.
> >3. There is also an issue with attempting to deploy Spring Data Geode
> >functions that we should try to work out.
> >
> > Anything else that anyone is aware of?
> >
> >
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: 631-835-4771
> >
> > On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
> > wrote:
> >
> > > Agree with Anthony. A copy command would either duplicate what deploy
> > does
> > > by only putting files within as specific location in the server's
> > directory
> > > or creating a security nightmare if allowed to write anywhere on the
> > host.
> > >
> > >
> > > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
> wrote:
> > >
> > > > I think there are lots of great OS orchestration and automation
> tools.
> > > > I’m not sure I understand the need for `gfsh cp`.  If I could easily
> > grab
> > > > the member hostnames from `gfsh list members` and pipe them into
> mpssh
> > > (for
> > > > example) that would do the job.
> > > >
> > > > I *do* like the idea of an improved `gfsh deploy` that supports hot
> > > deploy
> > > > and reconfiguration.
> > > >
> > > > Anthony
> > > >
> > > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar  >
> > > > wrote:
> > > > >
> > > > > Some application may need to copy files to all the servers. These
> > files
> > > > > could either be data files or they could be configuration files
> > needed
> > > by
> > > > > the application or they could be jar files (that don't have
> functions
> > > but
> > > > > have say, spring data geode jar files) that need to be on the
> > server's
> > > > > classpath.
> > > > > We could accomplish this by enhancing the current gfsh "deploy"
> > command
> > > > to
> > > > > accept any kind of file and write it to the servers file system OR
> > > > create a
> > > > > new gfsh "copy" command to copy any arbitrary file to the servers.
> > > > > I would personally like to repurpose the deploy command but would
> > like
> > > to
> > > > > hear the community's opinion.
> > > > >
> > > > > Thanks!
> > > >
> > > >
> > >
> >
>



-- 
-John
john.blum10101 (skype)

Re: copy files to servers

[John Blum]

1 more thing + correction

1 of the `deploy cache-loader` was meant to be `deploy cache-writer`.

Additionally, I may want to target certain Functions, Listeners, Loader,
Writers, etc, all separately at particular members as in...

gfsh> deploy function --name=F1 --members='server1, server2, server3';

gfsh> deploy cache-loader --name=L1 --members='server10';

-j

On Fri, Jan 6, 2017 at 11:19 AM, John Blum  wrote:

> How about...
>
> * deploy function
> * deploy cache-listener
> * deploy cache-loader
> * deploy cache-loader
> * deploy resource (jar, xml, properties, etc)
> * etc.
>
> Might as was make it explicit.  For instance, I may have a JAR file I just
> deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
> etc but I only want to deploy functions.
>
> Having 1 uber "deploy" command with many options gets cumbersome.
>
> It is a simple matter to introduce multiple command but have those
> commands share similar logic.  This would also enable different workflows
> for different commands in a more non-convoluted, maintainable way.
>
> These could be matched with corresponding `undeploy` commands.
>
> Food for thought,
>
> John
>
>
>
> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:
>
>> With appropriate constraints, a copy file type command could be secure.
>>
>> 1) don't use Apache Geode without security AND make the command require
>> authorization permissions
>> 2) limit the target directory to a directory under the working directory
>> of
>> the remote server
>> 3) rename it to "deploy resource" so people don't expect it to copy to an
>> arbitrary target directory on the remote machine
>>
>> Back to "deploy jar":
>>
>> The deploy command is only for deploying Apache Geode callbacks (Function,
>> CacheListener, etc). "deploy resource" such Spring jars or Spring xml
>> files
>> or anything similar does not overlap with "deploy jar". There is continued
>> confusion over what "deploy jar" is or does. I propose we rename it to
>> "deploy functions" or "deploy callbacks" or something along those lines to
>> end the confusion.
>>
>> On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:
>>
>> > So maybe a generic copy command is too insecure, I agree.
>> > What we should do is think about exactly what files we think we are
>> trying
>> > to deploy.
>> >
>> >1. I believe that there is a need to deploy dependency jars into the
>> >system classpath.
>> >2. I believe that there is also a desire to be able to deploy Spring
>> >Data Geode xml configuration files.
>> >3. There is also an issue with attempting to deploy Spring Data Geode
>> >functions that we should try to work out.
>> >
>> > Anything else that anyone is aware of?
>> >
>> >
>> >
>> >
>> > --
>> > Mike Stolz
>> > Principal Engineer, GemFire Product Manager
>> > Mobile: 631-835-4771
>> >
>> > On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
>> > wrote:
>> >
>> > > Agree with Anthony. A copy command would either duplicate what deploy
>> > does
>> > > by only putting files within as specific location in the server's
>> > directory
>> > > or creating a security nightmare if allowed to write anywhere on the
>> > host.
>> > >
>> > >
>> > > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
>> wrote:
>> > >
>> > > > I think there are lots of great OS orchestration and automation
>> tools.
>> > > > I’m not sure I understand the need for `gfsh cp`.  If I could easily
>> > grab
>> > > > the member hostnames from `gfsh list members` and pipe them into
>> mpssh
>> > > (for
>> > > > example) that would do the job.
>> > > >
>> > > > I *do* like the idea of an improved `gfsh deploy` that supports hot
>> > > deploy
>> > > > and reconfiguration.
>> > > >
>> > > > Anthony
>> > > >
>> > > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar <
>> sbawas...@pivotal.io>
>> > > > wrote:
>> > > > >
>> > > > > Some application may need to copy files to all the servers. These
>> > files
>> > > > > could either be data files or they could be configuration files
>> > needed
>> > > by
>> > > > > the application or they could be jar files (that don't have
>> functions
>> > > but
>> > > > > have say, spring data geode jar files) that need to be on the
>> > server's
>> > > > > classpath.
>> > > > > We could accomplish this by enhancing the current gfsh "deploy"
>> > command
>> > > > to
>> > > > > accept any kind of file and write it to the servers file system OR
>> > > > create a
>> > > > > new gfsh "copy" command to copy any arbitrary file to the servers.
>> > > > > I would personally like to repurpose the deploy command but would
>> > like
>> > > to
>> > > > > hear the community's opinion.
>> > > > >
>> > > > > Thanks!
>> > > >
>> > > >
>> > >
>> >
>>
>
>
>
> --
> -John
> john.blum10101 (skype)
>



-- 
-John
john.blum10101 (skype)

Re: copy files to servers

[Luke Shannon]

+1 on John's suggestion for explict commands

On Jan 6, 2017 2:20 PM, "John Blum"  wrote:

How about...

* deploy function
* deploy cache-listener
* deploy cache-loader
* deploy cache-loader
* deploy resource (jar, xml, properties, etc)
* etc.

Might as was make it explicit.  For instance, I may have a JAR file I just
deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
etc but I only want to deploy functions.

Having 1 uber "deploy" command with many options gets cumbersome.

It is a simple matter to introduce multiple command but have those commands
share similar logic.  This would also enable different workflows for
different commands in a more non-convoluted, maintainable way.

These could be matched with corresponding `undeploy` commands.

Food for thought,

John



On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:

> With appropriate constraints, a copy file type command could be secure.
>
> 1) don't use Apache Geode without security AND make the command require
> authorization permissions
> 2) limit the target directory to a directory under the working directory
of
> the remote server
> 3) rename it to "deploy resource" so people don't expect it to copy to an
> arbitrary target directory on the remote machine
>
> Back to "deploy jar":
>
> The deploy command is only for deploying Apache Geode callbacks (Function,
> CacheListener, etc). "deploy resource" such Spring jars or Spring xml
files
> or anything similar does not overlap with "deploy jar". There is continued
> confusion over what "deploy jar" is or does. I propose we rename it to
> "deploy functions" or "deploy callbacks" or something along those lines to
> end the confusion.
>
> On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:
>
> > So maybe a generic copy command is too insecure, I agree.
> > What we should do is think about exactly what files we think we are
> trying
> > to deploy.
> >
> >1. I believe that there is a need to deploy dependency jars into the
> >system classpath.
> >2. I believe that there is also a desire to be able to deploy Spring
> >Data Geode xml configuration files.
> >3. There is also an issue with attempting to deploy Spring Data Geode
> >functions that we should try to work out.
> >
> > Anything else that anyone is aware of?
> >
> >
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: 631-835-4771
> >
> > On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
> > wrote:
> >
> > > Agree with Anthony. A copy command would either duplicate what deploy
> > does
> > > by only putting files within as specific location in the server's
> > directory
> > > or creating a security nightmare if allowed to write anywhere on the
> > host.
> > >
> > >
> > > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
> wrote:
> > >
> > > > I think there are lots of great OS orchestration and automation
> tools.
> > > > I’m not sure I understand the need for `gfsh cp`.  If I could easily
> > grab
> > > > the member hostnames from `gfsh list members` and pipe them into
> mpssh
> > > (for
> > > > example) that would do the job.
> > > >
> > > > I *do* like the idea of an improved `gfsh deploy` that supports hot
> > > deploy
> > > > and reconfiguration.
> > > >
> > > > Anthony
> > > >
> > > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar  >
> > > > wrote:
> > > > >
> > > > > Some application may need to copy files to all the servers. These
> > files
> > > > > could either be data files or they could be configuration files
> > needed
> > > by
> > > > > the application or they could be jar files (that don't have
> functions
> > > but
> > > > > have say, spring data geode jar files) that need to be on the
> > server's
> > > > > classpath.
> > > > > We could accomplish this by enhancing the current gfsh "deploy"
> > command
> > > > to
> > > > > accept any kind of file and write it to the servers file system OR
> > > > create a
> > > > > new gfsh "copy" command to copy any arbitrary file to the servers.
> > > > > I would personally like to repurpose the deploy command but would
> > like
> > > to
> > > > > hear the community's opinion.
> > > > >
> > > > > Thanks!
> > > >
> > > >
> > >
> >
>



--
-John
john.blum10101 (skype)

Re: Review Request 55236: GEODE-2271 Reduce pdx type id generation for string fields in JSON

[Hitesh Khamesra]

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

(Updated Jan. 6, 2017, 7:30 p.m.)


Review request for geode, Bruce Schuchardt and Udo Kohlmeyer.


Changes
---

Updated diff based on review


Repository: geode


Description
---

GEODE-2271 JSOnFormatter can generate three pdxTypeId for one json field.

JSON field can have 3 values(fieldValue, NULL, fieldNotExist), this
causes 3 pdxTypeIds. To reuduce this we merged first two values in 
one pdxType.

Added unit test for it


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/pdx/JSONFormatter.java ff2ce04 
  geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java 
4ebc33d 
  
geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceHelper.java
 e957cd6 
  geode-core/src/test/java/org/apache/geode/pdx/Employee.java cfb46b5 
  geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java 
979da13 
  geode-core/src/test/java/org/apache/geode/pdx/PdxStringJUnitTest.java c072e14 
  geode-core/src/test/java/org/apache/geode/pdx/TestObjectForJSONFormatter.java 
ca0abc3 

Diff: https://reviews.apache.org/r/55236/diff/


Testing
---


Thanks,

Hitesh Khamesra

Re: copy files to servers

[Luke Shannon]

One question John, if my CacheWriter had depenancies of its own, would the
expectation be I bundle them as a fat jar and use the explict deploy
cachewriter command?


On Jan 6, 2017 2:28 PM, "Luke Shannon"  wrote:

> +1 on John's suggestion for explict commands
>
> On Jan 6, 2017 2:20 PM, "John Blum"  wrote:
>
> How about...
>
> * deploy function
> * deploy cache-listener
> * deploy cache-loader
> * deploy cache-loader
> * deploy resource (jar, xml, properties, etc)
> * etc.
>
> Might as was make it explicit.  For instance, I may have a JAR file I just
> deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
> etc but I only want to deploy functions.
>
> Having 1 uber "deploy" command with many options gets cumbersome.
>
> It is a simple matter to introduce multiple command but have those commands
> share similar logic.  This would also enable different workflows for
> different commands in a more non-convoluted, maintainable way.
>
> These could be matched with corresponding `undeploy` commands.
>
> Food for thought,
>
> John
>
>
>
> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:
>
> > With appropriate constraints, a copy file type command could be secure.
> >
> > 1) don't use Apache Geode without security AND make the command require
> > authorization permissions
> > 2) limit the target directory to a directory under the working directory
> of
> > the remote server
> > 3) rename it to "deploy resource" so people don't expect it to copy to an
> > arbitrary target directory on the remote machine
> >
> > Back to "deploy jar":
> >
> > The deploy command is only for deploying Apache Geode callbacks
> (Function,
> > CacheListener, etc). "deploy resource" such Spring jars or Spring xml
> files
> > or anything similar does not overlap with "deploy jar". There is
> continued
> > confusion over what "deploy jar" is or does. I propose we rename it to
> > "deploy functions" or "deploy callbacks" or something along those lines
> to
> > end the confusion.
> >
> > On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:
> >
> > > So maybe a generic copy command is too insecure, I agree.
> > > What we should do is think about exactly what files we think we are
> > trying
> > > to deploy.
> > >
> > >1. I believe that there is a need to deploy dependency jars into the
> > >system classpath.
> > >2. I believe that there is also a desire to be able to deploy Spring
> > >Data Geode xml configuration files.
> > >3. There is also an issue with attempting to deploy Spring Data
> Geode
> > >functions that we should try to work out.
> > >
> > > Anything else that anyone is aware of?
> > >
> > >
> > >
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: 631-835-4771
> > >
> > > On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
> > > wrote:
> > >
> > > > Agree with Anthony. A copy command would either duplicate what deploy
> > > does
> > > > by only putting files within as specific location in the server's
> > > directory
> > > > or creating a security nightmare if allowed to write anywhere on the
> > > host.
> > > >
> > > >
> > > > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
> > wrote:
> > > >
> > > > > I think there are lots of great OS orchestration and automation
> > tools.
> > > > > I’m not sure I understand the need for `gfsh cp`.  If I could
> easily
> > > grab
> > > > > the member hostnames from `gfsh list members` and pipe them into
> > mpssh
> > > > (for
> > > > > example) that would do the job.
> > > > >
> > > > > I *do* like the idea of an improved `gfsh deploy` that supports hot
> > > > deploy
> > > > > and reconfiguration.
> > > > >
> > > > > Anthony
> > > > >
> > > > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar <
> sbawas...@pivotal.io
> > >
> > > > > wrote:
> > > > > >
> > > > > > Some application may need to copy files to all the servers. These
> > > files
> > > > > > could either be data files or they could be configuration files
> > > needed
> > > > by
> > > > > > the application or they could be jar files (that don't have
> > functions
> > > > but
> > > > > > have say, spring data geode jar files) that need to be on the
> > > server's
> > > > > > classpath.
> > > > > > We could accomplish this by enhancing the current gfsh "deploy"
> > > command
> > > > > to
> > > > > > accept any kind of file and write it to the servers file system
> OR
> > > > > create a
> > > > > > new gfsh "copy" command to copy any arbitrary file to the
> servers.
> > > > > > I would personally like to repurpose the deploy command but would
> > > like
> > > > to
> > > > > > hear the community's opinion.
> > > > > >
> > > > > > Thanks!
> > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>
>
>

Re: copy files to servers

[Udo Kohlmeyer]

In some ways that is a great idea but sometimes too explicit... Do 
we expect them to have fine grained jars?
Also how do we handle dependencies as a single util class might be 
used by both a cache-listener and a partition listener... is the 
expectation that we update the dependent util class for one but not the 
other


It's a very grey area

On 1/6/17 11:19, John Blum wrote:

How about...

* deploy function
* deploy cache-listener
* deploy cache-loader
* deploy cache-loader
* deploy resource (jar, xml, properties, etc)
* etc.

Might as was make it explicit.  For instance, I may have a JAR file I just
deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
etc but I only want to deploy functions.

Having 1 uber "deploy" command with many options gets cumbersome.

It is a simple matter to introduce multiple command but have those commands
share similar logic.  This would also enable different workflows for
different commands in a more non-convoluted, maintainable way.

These could be matched with corresponding `undeploy` commands.

Food for thought,

John



On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:


With appropriate constraints, a copy file type command could be secure.

1) don't use Apache Geode without security AND make the command require
authorization permissions
2) limit the target directory to a directory under the working directory of
the remote server
3) rename it to "deploy resource" so people don't expect it to copy to an
arbitrary target directory on the remote machine

Back to "deploy jar":

The deploy command is only for deploying Apache Geode callbacks (Function,
CacheListener, etc). "deploy resource" such Spring jars or Spring xml files
or anything similar does not overlap with "deploy jar". There is continued
confusion over what "deploy jar" is or does. I propose we rename it to
"deploy functions" or "deploy callbacks" or something along those lines to
end the confusion.

On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:


So maybe a generic copy command is too insecure, I agree.
What we should do is think about exactly what files we think we are

trying

to deploy.

1. I believe that there is a need to deploy dependency jars into the
system classpath.
2. I believe that there is also a desire to be able to deploy Spring
Data Geode xml configuration files.
3. There is also an issue with attempting to deploy Spring Data Geode
functions that we should try to work out.

Anything else that anyone is aware of?




--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
wrote:


Agree with Anthony. A copy command would either duplicate what deploy

does

by only putting files within as specific location in the server's

directory

or creating a security nightmare if allowed to write anywhere on the

host.


On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 

wrote:

I think there are lots of great OS orchestration and automation

tools.

I’m not sure I understand the need for `gfsh cp`.  If I could easily

grab

the member hostnames from `gfsh list members` and pipe them into

mpssh

(for

example) that would do the job.

I *do* like the idea of an improved `gfsh deploy` that supports hot

deploy

and reconfiguration.

Anthony


On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar 
wrote:

Some application may need to copy files to all the servers. These

files

could either be data files or they could be configuration files

needed

by

the application or they could be jar files (that don't have

functions

but

have say, spring data geode jar files) that need to be on the

server's

classpath.
We could accomplish this by enhancing the current gfsh "deploy"

command

to

accept any kind of file and write it to the servers file system OR

create a

new gfsh "copy" command to copy any arbitrary file to the servers.
I would personally like to repurpose the deploy command but would

like

to

hear the community's opinion.

Thanks!

Re: copy files to servers

[Kirk Lund]

+1 I like no ambiguity

On Fri, Jan 6, 2017 at 11:28 AM Luke Shannon  wrote:

> +1 on John's suggestion for explict commands
>
>
>
> On Jan 6, 2017 2:20 PM, "John Blum"  wrote:
>
>
>
> How about...
>
>
>
> * deploy function
>
> * deploy cache-listener
>
> * deploy cache-loader
>
> * deploy cache-loader
>
> * deploy resource (jar, xml, properties, etc)
>
> * etc.
>
>
>
> Might as was make it explicit.  For instance, I may have a JAR file I just
>
> deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
>
> etc but I only want to deploy functions.
>
>
>
> Having 1 uber "deploy" command with many options gets cumbersome.
>
>
>
> It is a simple matter to introduce multiple command but have those commands
>
> share similar logic.  This would also enable different workflows for
>
> different commands in a more non-convoluted, maintainable way.
>
>
>
> These could be matched with corresponding `undeploy` commands.
>
>
>
> Food for thought,
>
>
>
> John
>
>
>
>
>
>
>
> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:
>
>
>
> > With appropriate constraints, a copy file type command could be secure.
>
> >
>
> > 1) don't use Apache Geode without security AND make the command require
>
> > authorization permissions
>
> > 2) limit the target directory to a directory under the working directory
>
> of
>
> > the remote server
>
> > 3) rename it to "deploy resource" so people don't expect it to copy to an
>
> > arbitrary target directory on the remote machine
>
> >
>
> > Back to "deploy jar":
>
> >
>
> > The deploy command is only for deploying Apache Geode callbacks
> (Function,
>
> > CacheListener, etc). "deploy resource" such Spring jars or Spring xml
>
> files
>
> > or anything similar does not overlap with "deploy jar". There is
> continued
>
> > confusion over what "deploy jar" is or does. I propose we rename it to
>
> > "deploy functions" or "deploy callbacks" or something along those lines
> to
>
> > end the confusion.
>
> >
>
> > On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:
>
> >
>
> > > So maybe a generic copy command is too insecure, I agree.
>
> > > What we should do is think about exactly what files we think we are
>
> > trying
>
> > > to deploy.
>
> > >
>
> > >1. I believe that there is a need to deploy dependency jars into the
>
> > >system classpath.
>
> > >2. I believe that there is also a desire to be able to deploy Spring
>
> > >Data Geode xml configuration files.
>
> > >3. There is also an issue with attempting to deploy Spring Data
> Geode
>
> > >functions that we should try to work out.
>
> > >
>
> > > Anything else that anyone is aware of?
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > --
>
> > > Mike Stolz
>
> > > Principal Engineer, GemFire Product Manager
>
> > > Mobile: 631-835-4771
>
> > >
>
> > > On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
>
> > > wrote:
>
> > >
>
> > > > Agree with Anthony. A copy command would either duplicate what deploy
>
> > > does
>
> > > > by only putting files within as specific location in the server's
>
> > > directory
>
> > > > or creating a security nightmare if allowed to write anywhere on the
>
> > > host.
>
> > > >
>
> > > >
>
> > > > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
>
> > wrote:
>
> > > >
>
> > > > > I think there are lots of great OS orchestration and automation
>
> > tools.
>
> > > > > I’m not sure I understand the need for `gfsh cp`.  If I could
> easily
>
> > > grab
>
> > > > > the member hostnames from `gfsh list members` and pipe them into
>
> > mpssh
>
> > > > (for
>
> > > > > example) that would do the job.
>
> > > > >
>
> > > > > I *do* like the idea of an improved `gfsh deploy` that supports hot
>
> > > > deploy
>
> > > > > and reconfiguration.
>
> > > > >
>
> > > > > Anthony
>
> > > > >
>
> > > > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar <
> sbawas...@pivotal.io
>
> > >
>
> > > > > wrote:
>
> > > > > >
>
> > > > > > Some application may need to copy files to all the servers. These
>
> > > files
>
> > > > > > could either be data files or they could be configuration files
>
> > > needed
>
> > > > by
>
> > > > > > the application or they could be jar files (that don't have
>
> > functions
>
> > > > but
>
> > > > > > have say, spring data geode jar files) that need to be on the
>
> > > server's
>
> > > > > > classpath.
>
> > > > > > We could accomplish this by enhancing the current gfsh "deploy"
>
> > > command
>
> > > > > to
>
> > > > > > accept any kind of file and write it to the servers file system
> OR
>
> > > > > create a
>
> > > > > > new gfsh "copy" command to copy any arbitrary file to the
> servers.
>
> > > > > > I would personally like to repurpose the deploy command but would
>
> > > like
>
> > > > to
>
> > > > > > hear the community's opinion.
>
> > > > > >
>
> > > > > > Thanks!
>
> > > > >
>
> > > > >
>
> > > >
>
> > >
>
> >
>
>
>
>
>
>
>
> --
>
> -John
>
> john.blum10101 (skype)
>
>

Re: copy files to servers

[John Blum]

@Luke-

*>  if my CacheWriter had depenancies of its own, would the expectation be
I bundle them as a fat jar and use the explict deploy cachewriter command?*

Yes, I would envisions something like this...

gfsh> deploy resource --name=myApplicationDependencies.jar

gfsh> deploy cache-writer --name=x.y.z.MyApplicationCacheWriter
--members=serverX

The myApplicationDependencies.jar file would contain the
x.y.z.MyApplicationCacheWriter.class and all the dependencies it needs.

@Udo-

*> Do we expect them to have fine grained jars?*

I think we should assume that we can expect, and we should be ready for
anything our users throw at us.  Either we handle it correctly and very
explicitly, or we give them a very detailed message of what went wrong
along and possible ways to fix it.

I was not thinking a user would be expected to package *Functions*,
*Listeners*, *Loaders*, *Writers*, etc individually, in separate JAR files,
although nothing should prevent them from doing so if they so choose to
organize things that way.  Rather, they could deploy a single application
JAR file in 1 fair swoop that contains all the artifacts their application
will potentially need at runtime.  As such, `deploy resource` would no
longer be responsible for construction/initializing and registering these
components.  It's sole responsibility would be to "upload" the artifact(s)
where they are needed by the application.

Therefore, the other individual `deploy` commands would then determine what
gets used/put-into-service (e.g. `deploy function` to construct/initialize
and register a Function; `deploy cache-loader` to construct/initialize and
register a CacheLoader callback for read-through on cache miss; etc).

It would be expected that all these application components would have been
previously deployed first using `deploy resource`, before invoking the
other `deploy' commands.  This seems reasonable to me.

Perhaps to avoid confusion, `deploy resource` could even be called `upload
resource`.

As to how finely grained components are packaged, i.e. individual JAR
files, a single JAR, or 1 big FAT JAR (a JAR of JARS, classes, and other
resource files... XML, properties, etc) that is a problem for the
ClassLoader to work out.

-j


On Fri, Jan 6, 2017 at 11:37 AM, Udo Kohlmeyer 
wrote:

> In some ways that is a great idea but sometimes too explicit... Do we
> expect them to have fine grained jars?
> Also how do we handle dependencies as a single util class might be
> used by both a cache-listener and a partition listener... is the
> expectation that we update the dependent util class for one but not the
> other
>
> It's a very grey area
>
>
> On 1/6/17 11:19, John Blum wrote:
>
>> How about...
>>
>> * deploy function
>> * deploy cache-listener
>> * deploy cache-loader
>> * deploy cache-loader
>> * deploy resource (jar, xml, properties, etc)
>> * etc.
>>
>> Might as was make it explicit.  For instance, I may have a JAR file I just
>> deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
>> etc but I only want to deploy functions.
>>
>> Having 1 uber "deploy" command with many options gets cumbersome.
>>
>> It is a simple matter to introduce multiple command but have those
>> commands
>> share similar logic.  This would also enable different workflows for
>> different commands in a more non-convoluted, maintainable way.
>>
>> These could be matched with corresponding `undeploy` commands.
>>
>> Food for thought,
>>
>> John
>>
>>
>>
>> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:
>>
>> With appropriate constraints, a copy file type command could be secure.
>>>
>>> 1) don't use Apache Geode without security AND make the command require
>>> authorization permissions
>>> 2) limit the target directory to a directory under the working directory
>>> of
>>> the remote server
>>> 3) rename it to "deploy resource" so people don't expect it to copy to an
>>> arbitrary target directory on the remote machine
>>>
>>> Back to "deploy jar":
>>>
>>> The deploy command is only for deploying Apache Geode callbacks
>>> (Function,
>>> CacheListener, etc). "deploy resource" such Spring jars or Spring xml
>>> files
>>> or anything similar does not overlap with "deploy jar". There is
>>> continued
>>> confusion over what "deploy jar" is or does. I propose we rename it to
>>> "deploy functions" or "deploy callbacks" or something along those lines
>>> to
>>> end the confusion.
>>>
>>> On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:
>>>
>>> So maybe a generic copy command is too insecure, I agree.
 What we should do is think about exactly what files we think we are

>>> trying
>>>
 to deploy.

 1. I believe that there is a need to deploy dependency jars into the
 system classpath.
 2. I believe that there is also a desire to be able to deploy Spring
 Data Geode xml configuration files.
 3. There is also an issue with attempting to deploy Spring Data
 Geode
>>

Re: copy files to servers

[Anthony Baker]

Hmmm, I agree with Udo.  I’d like to push a new version of my application with 
a single idempotent command.  The server should be smart enough to figure out 
what's in my bundle and understand how to deploy it including any dependencies 
(because who writes dependency-free code?).  

I do want some lifecycle hooks to alloc/free resources.  This seems 
conceptually similar to the “war” model which is pretty familiar to most Java 
devs.

Anthony

> On Jan 6, 2017, at 11:37 AM, Udo Kohlmeyer  wrote:
> 
> In some ways that is a great idea but sometimes too explicit... Do we 
> expect them to have fine grained jars?
> Also how do we handle dependencies as a single util class might be used 
> by both a cache-listener and a partition listener... is the expectation that 
> we update the dependent util class for one but not the other
> 
> It's a very grey area
> 
> On 1/6/17 11:19, John Blum wrote:
>> How about...
>> 
>> * deploy function
>> * deploy cache-listener
>> * deploy cache-loader
>> * deploy cache-loader
>> * deploy resource (jar, xml, properties, etc)
>> * etc.
>> 
>> Might as was make it explicit.  For instance, I may have a JAR file I just
>> deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
>> etc but I only want to deploy functions.
>> 
>> Having 1 uber "deploy" command with many options gets cumbersome.
>> 
>> It is a simple matter to introduce multiple command but have those commands
>> share similar logic.  This would also enable different workflows for
>> different commands in a more non-convoluted, maintainable way.
>> 
>> These could be matched with corresponding `undeploy` commands.
>> 
>> Food for thought,
>> 
>> John
>> 
>> 
>> 
>> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:
>> 
>>> With appropriate constraints, a copy file type command could be secure.
>>> 
>>> 1) don't use Apache Geode without security AND make the command require
>>> authorization permissions
>>> 2) limit the target directory to a directory under the working directory of
>>> the remote server
>>> 3) rename it to "deploy resource" so people don't expect it to copy to an
>>> arbitrary target directory on the remote machine
>>> 
>>> Back to "deploy jar":
>>> 
>>> The deploy command is only for deploying Apache Geode callbacks (Function,
>>> CacheListener, etc). "deploy resource" such Spring jars or Spring xml files
>>> or anything similar does not overlap with "deploy jar". There is continued
>>> confusion over what "deploy jar" is or does. I propose we rename it to
>>> "deploy functions" or "deploy callbacks" or something along those lines to
>>> end the confusion.
>>> 
>>> On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:
>>> 
 So maybe a generic copy command is too insecure, I agree.
 What we should do is think about exactly what files we think we are
>>> trying
 to deploy.
 
1. I believe that there is a need to deploy dependency jars into the
system classpath.
2. I believe that there is also a desire to be able to deploy Spring
Data Geode xml configuration files.
3. There is also an issue with attempting to deploy Spring Data Geode
functions that we should try to work out.
 
 Anything else that anyone is aware of?
 
 
 
 
 --
 Mike Stolz
 Principal Engineer, GemFire Product Manager
 Mobile: 631-835-4771
 
 On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
 wrote:
 
> Agree with Anthony. A copy command would either duplicate what deploy
 does
> by only putting files within as specific location in the server's
 directory
> or creating a security nightmare if allowed to write anywhere on the
 host.
> 
> On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
>>> wrote:
>> I think there are lots of great OS orchestration and automation
>>> tools.
>> I’m not sure I understand the need for `gfsh cp`.  If I could easily
 grab
>> the member hostnames from `gfsh list members` and pipe them into
>>> mpssh
> (for
>> example) that would do the job.
>> 
>> I *do* like the idea of an improved `gfsh deploy` that supports hot
> deploy
>> and reconfiguration.
>> 
>> Anthony
>> 
>>> On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar > wrote:
>>> Some application may need to copy files to all the servers. These
 files
>>> could either be data files or they could be configuration files
 needed
> by
>>> the application or they could be jar files (that don't have
>>> functions
> but
>>> have say, spring data geode jar files) that need to be on the
 server's
>>> classpath.
>>> We could accomplish this by enhancing the current gfsh "deploy"
 command
>> to
>>> accept any kind of file and write it to the servers file system OR
>> create a
>>> new gfsh "copy" command to copy any arbitrary file to the servers.
>>> I would personally like to

Re: copy files to servers

[Dan Smith]

I don't understand the difference between this proposal:

> gfsh> deploy resource --name=myApplicationDependencies.jar
> gfsh> deploy cache-writer --name=x.y.z.MyApplicationCacheWriter
--members=serverX

And this example, which you can already do today:

gfsh> depoy --jar=myApplicationStuff.jar
gfsh> alter region --cache-writer=x.y.z.MyApplicationCacheWriter


As far as the hot swapping classes goes, I agree that that is a really
tricky problem. I also agree with Udo that a fine grained approach probably
won't work. Since classes tend to be interconnected and refer to each
other, you really need swap out everything at once. Application servers do
this with war files by serializing all of the session data and creating a
new classloader with the war file. This is turning gemfire into a container
as everyone is pointing out.

-Dan

On Fri, Jan 6, 2017 at 12:00 PM, John Blum  wrote:

> @Luke-
>
> *>  if my CacheWriter had depenancies of its own, would the expectation be
> I bundle them as a fat jar and use the explict deploy cachewriter command?*
>
> Yes, I would envisions something like this...
>
> gfsh> deploy resource --name=myApplicationDependencies.jar
>
> gfsh> deploy cache-writer --name=x.y.z.MyApplicationCacheWriter
> --members=serverX
>
> The myApplicationDependencies.jar file would contain the
> x.y.z.MyApplicationCacheWriter.class and all the dependencies it needs.
>
> @Udo-
>
> *> Do we expect them to have fine grained jars?*
>
> I think we should assume that we can expect, and we should be ready for
> anything our users throw at us.  Either we handle it correctly and very
> explicitly, or we give them a very detailed message of what went wrong
> along and possible ways to fix it.
>
> I was not thinking a user would be expected to package *Functions*,
> *Listeners*, *Loaders*, *Writers*, etc individually, in separate JAR files,
> although nothing should prevent them from doing so if they so choose to
> organize things that way.  Rather, they could deploy a single application
> JAR file in 1 fair swoop that contains all the artifacts their application
> will potentially need at runtime.  As such, `deploy resource` would no
> longer be responsible for construction/initializing and registering these
> components.  It's sole responsibility would be to "upload" the artifact(s)
> where they are needed by the application.
>
> Therefore, the other individual `deploy` commands would then determine what
> gets used/put-into-service (e.g. `deploy function` to construct/initialize
> and register a Function; `deploy cache-loader` to construct/initialize and
> register a CacheLoader callback for read-through on cache miss; etc).
>
> It would be expected that all these application components would have been
> previously deployed first using `deploy resource`, before invoking the
> other `deploy' commands.  This seems reasonable to me.
>
> Perhaps to avoid confusion, `deploy resource` could even be called `upload
> resource`.
>
> As to how finely grained components are packaged, i.e. individual JAR
> files, a single JAR, or 1 big FAT JAR (a JAR of JARS, classes, and other
> resource files... XML, properties, etc) that is a problem for the
> ClassLoader to work out.
>
> -j
>
>
> On Fri, Jan 6, 2017 at 11:37 AM, Udo Kohlmeyer 
> wrote:
>
> > In some ways that is a great idea but sometimes too explicit... Do we
> > expect them to have fine grained jars?
> > Also how do we handle dependencies as a single util class might be
> > used by both a cache-listener and a partition listener... is the
> > expectation that we update the dependent util class for one but not the
> > other
> >
> > It's a very grey area
> >
> >
> > On 1/6/17 11:19, John Blum wrote:
> >
> >> How about...
> >>
> >> * deploy function
> >> * deploy cache-listener
> >> * deploy cache-loader
> >> * deploy cache-loader
> >> * deploy resource (jar, xml, properties, etc)
> >> * etc.
> >>
> >> Might as was make it explicit.  For instance, I may have a JAR file I
> just
> >> deployed (uploaded) that contains Functions, Listeners, Loaders,
> Writers,
> >> etc but I only want to deploy functions.
> >>
> >> Having 1 uber "deploy" command with many options gets cumbersome.
> >>
> >> It is a simple matter to introduce multiple command but have those
> >> commands
> >> share similar logic.  This would also enable different workflows for
> >> different commands in a more non-convoluted, maintainable way.
> >>
> >> These could be matched with corresponding `undeploy` commands.
> >>
> >> Food for thought,
> >>
> >> John
> >>
> >>
> >>
> >> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:
> >>
> >> With appropriate constraints, a copy file type command could be secure.
> >>>
> >>> 1) don't use Apache Geode without security AND make the command require
> >>> authorization permissions
> >>> 2) limit the target directory to a directory under the working
> directory
> >>> of
> >>> the remote server
> >>> 3) rename it to "deploy resource" so people don't ex

Re: Review Request 55275: GEODE-2278 - Fix an NPE with inconsistent lucene indexes

[Barry Oglesby]

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


Ship it!




Ship It!

- Barry Oglesby


On Jan. 6, 2017, 6:49 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55275/
> ---
> 
> (Updated Jan. 6, 2017, 6:49 p.m.)
> 
> 
> Review request for geode and Barry Oglesby.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If a member without a lucene index is created first, we should throw a
> reasonable error rather than an NPE.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> 1343395da972ac5ef07feb424626840b7aea2e99 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneIndexCreationDUnitTest.java
>  7e50636eaed9bc277f6b25c163695a7c78451610 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/test/LuceneTestUtilities.java
>  cb28e88913e9424db075a1b5cf15f4ad89921817 
> 
> Diff: https://reviews.apache.org/r/55275/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: copy files to servers

[Jacob Barrett]

We need to take a lesson from any modern Java application an embrace class
loader modularization. The only thing in the system class path should be
very minimal bootstrap jar. The rest of our needs should be addressed by
well organized and isolated class loaders.

The deployment of a function, or set of functions, should operate in a
fully isolated class loader. The deployment should include all dependencies
except for the APIs provided by the Geode framework.

-Jake

On Fri, Jan 6, 2017 at 8:13 AM Michael Stolz  wrote:

> So maybe a generic copy command is too insecure, I agree.
> What we should do is think about exactly what files we think we are trying
> to deploy.
>
>1. I believe that there is a need to deploy dependency jars into the
>system classpath.
>2. I believe that there is also a desire to be able to deploy Spring
>Data Geode xml configuration files.
>3. There is also an issue with attempting to deploy Spring Data Geode
>functions that we should try to work out.
>
> Anything else that anyone is aware of?
>
>
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: 631-835-4771 <(631)%20835-4771>
>
> On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
> wrote:
>
> > Agree with Anthony. A copy command would either duplicate what deploy
> does
> > by only putting files within as specific location in the server's
> directory
> > or creating a security nightmare if allowed to write anywhere on the
> host.
> >
> >
> > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker  wrote:
> >
> > > I think there are lots of great OS orchestration and automation tools.
> > > I’m not sure I understand the need for `gfsh cp`.  If I could easily
> grab
> > > the member hostnames from `gfsh list members` and pipe them into mpssh
> > (for
> > > example) that would do the job.
> > >
> > > I *do* like the idea of an improved `gfsh deploy` that supports hot
> > deploy
> > > and reconfiguration.
> > >
> > > Anthony
> > >
> > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar 
> > > wrote:
> > > >
> > > > Some application may need to copy files to all the servers. These
> files
> > > > could either be data files or they could be configuration files
> needed
> > by
> > > > the application or they could be jar files (that don't have functions
> > but
> > > > have say, spring data geode jar files) that need to be on the
> server's
> > > > classpath.
> > > > We could accomplish this by enhancing the current gfsh "deploy"
> command
> > > to
> > > > accept any kind of file and write it to the servers file system OR
> > > create a
> > > > new gfsh "copy" command to copy any arbitrary file to the servers.
> > > > I would personally like to repurpose the deploy command but would
> like
> > to
> > > > hear the community's opinion.
> > > >
> > > > Thanks!
> > >
> > >
> >
>

Review Request 55280: GEODE-2142: Remove JSON from pulse

[Anthony Baker]

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

Review request for geode, Jinmei Liao, Kirk Lund, and Mark Bretl.


Repository: geode


Description
---

GEODE-2142: Add JSON usage to NOTICE 

GEODE-2142: Remove JSON dependency from pulse

Remove the Cat-X licensed JSON software from geode-pulse and replace
it with the friendly open-json replacement.  See
https://github.com/tdunning/open-json.

Update copyright date in NOTICE


Diffs
-

  NOTICE 4801b2aedf4f254c85cba9f27d2f99d2ca2e046b 
  geode-assembly/src/main/dist/NOTICE 83d0f3313a01881c9c651077036c17f962cd38b9 
  geode-pulse/build.gradle 94f26f7a4106ea085ba1bc9a7001967f6b47a863 
  geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CDL.java 
6243f8f599342dbdf00d3b541dfeca9da5def508 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/Cookie.java
 1a0fa6fb7c1edd8b81bd4513ea6786a8ba4ba59c 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CookieList.java
 99498f500fec9d85a30b610564c706731a55ed68 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTP.java 
234d2bddc483f71503f84886be949f2b93a7ddd6 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTPTokener.java
 09b68d872f492f65cff14a02997dbae657027992 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONArray.java
 0db27363e51eaa4e7d40724ea82ed29975df46c4 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONException.java
 fbd8866cd59817b588b84ae3bceb6e39f49fa8e2 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONML.java
 fc19ca549da14441c8895bce56d46bf880b13c90 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONObject.java
 13f2ccad8c24a346ef8eb20cd195f5bf53211eeb 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONString.java
 45585c75dbe5c0dd50359117713e078263dfb7b3 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONStringer.java
 8c5ff0826d5f6ad998d39ee73ef4a255e5fc0423 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONTokener.java
 0f4b7ee8f017c1f561f954dab1e409236d382bf2 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONWriter.java
 dea900ab240b9a1b25079dec43c1e775e7caef76 
  geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/README 
2d7cdcf8a0ccdd29e0b1a3337da4338a51649bce 
  geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XML.java 
25675f89b6d2e22fced09dd366b18753f28b3ab7 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XMLTokener.java
 ff81731e11b49b649b92580fd169440c734a1006 
  geode-pulse/src/main/webapp/META-INF/NOTICE 
706eda265cf0b54c73d01df85c0a79bde9082d8a 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/BaseServiceTest.java
 ccc147d1533142d54c8c7378c935da8f5e3234f5 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionServiceTest.java
 77e6dd89340c59f7c15363a1d878ca3b6165d90a 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionsMemberServiceTest.java
 512cfc78e811a3234f170b243cf3983a96fc4788 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/MemberGatewayHubServiceTest.java
 980a772a6a43a60befe3f4cec2c898b3e62ad038 
  geode-web-api/src/main/webapp/META-INF/NOTICE 
21082b6de4fbd7ba4ec4bcb61e9e1bfda5ac162a 
  geode-web/src/main/webapp/META-INF/NOTICE 
8c6e1d7faf3188599305f44c44318f6e6cfd00e6 
  gradle/dependency-versions.properties 
828b0882d0813919e699d1ec83c7ba9c59f0220e 

Diff: https://reviews.apache.org/r/55280/diff/


Testing
---


Thanks,

Anthony Baker

Re: copy files to servers

[John Blum]

*@Anthony-*

*> The server should be smart enough to figure out what's in my bundle and
understand how to deploy it including any dependencies*

Agreed on the dependencies part, but... "*smart enough to figure out what's
in my bundle*".  Hmmm.  Beyond recognizing Geode/GemFire
objects/interfaces, I don't see how this is likely.

For instance, I recently added the ability (SGF-106
 [1]) in SDG to create Indexes using
Annotations on application domain objects/entities properties/fields when
using the SDG mapping support

[2]
(and SD *Repositories*).  Currently, Geode/GemFire does not even recognize
SDG "defined" (annotated) Functions.  How is it going to know (or how I am
I going tell it) about Index annotations now, or something else.  Of
course, Geode/GemFire could delegate to the *Spring* container in both
instances, but that does not cover cases where *Spring* is not used.

[1] https://jira.spring.io/browse/SGF-106
[2]
http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#mapping


On Fri, Jan 6, 2017 at 12:49 PM, Jacob Barrett  wrote:

> We need to take a lesson from any modern Java application an embrace class
> loader modularization. The only thing in the system class path should be
> very minimal bootstrap jar. The rest of our needs should be addressed by
> well organized and isolated class loaders.
>
> The deployment of a function, or set of functions, should operate in a
> fully isolated class loader. The deployment should include all dependencies
> except for the APIs provided by the Geode framework.
>
> -Jake
>
> On Fri, Jan 6, 2017 at 8:13 AM Michael Stolz  wrote:
>
> > So maybe a generic copy command is too insecure, I agree.
> > What we should do is think about exactly what files we think we are
> trying
> > to deploy.
> >
> >1. I believe that there is a need to deploy dependency jars into the
> >system classpath.
> >2. I believe that there is also a desire to be able to deploy Spring
> >Data Geode xml configuration files.
> >3. There is also an issue with attempting to deploy Spring Data Geode
> >functions that we should try to work out.
> >
> > Anything else that anyone is aware of?
> >
> >
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: 631-835-4771 <(631)%20835-4771>
> >
> > On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
> > wrote:
> >
> > > Agree with Anthony. A copy command would either duplicate what deploy
> > does
> > > by only putting files within as specific location in the server's
> > directory
> > > or creating a security nightmare if allowed to write anywhere on the
> > host.
> > >
> > >
> > > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
> wrote:
> > >
> > > > I think there are lots of great OS orchestration and automation
> tools.
> > > > I’m not sure I understand the need for `gfsh cp`.  If I could easily
> > grab
> > > > the member hostnames from `gfsh list members` and pipe them into
> mpssh
> > > (for
> > > > example) that would do the job.
> > > >
> > > > I *do* like the idea of an improved `gfsh deploy` that supports hot
> > > deploy
> > > > and reconfiguration.
> > > >
> > > > Anthony
> > > >
> > > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar  >
> > > > wrote:
> > > > >
> > > > > Some application may need to copy files to all the servers. These
> > files
> > > > > could either be data files or they could be configuration files
> > needed
> > > by
> > > > > the application or they could be jar files (that don't have
> functions
> > > but
> > > > > have say, spring data geode jar files) that need to be on the
> > server's
> > > > > classpath.
> > > > > We could accomplish this by enhancing the current gfsh "deploy"
> > command
> > > > to
> > > > > accept any kind of file and write it to the servers file system OR
> > > > create a
> > > > > new gfsh "copy" command to copy any arbitrary file to the servers.
> > > > > I would personally like to repurpose the deploy command but would
> > like
> > > to
> > > > > hear the community's opinion.
> > > > >
> > > > > Thanks!
> > > >
> > > >
> > >
> >
>



-- 
-John
john.blum10101 (skype)

Re: Review Request 55280: GEODE-2142: Remove JSON from pulse

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On Jan. 6, 2017, 9:09 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55280/
> ---
> 
> (Updated Jan. 6, 2017, 9:09 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kirk Lund, and Mark Bretl.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2142: Add JSON usage to NOTICE 
> 
> GEODE-2142: Remove JSON dependency from pulse
> 
> Remove the Cat-X licensed JSON software from geode-pulse and replace
> it with the friendly open-json replacement.  See
> https://github.com/tdunning/open-json.
> 
> Update copyright date in NOTICE
> 
> 
> Diffs
> -
> 
>   NOTICE 4801b2aedf4f254c85cba9f27d2f99d2ca2e046b 
>   geode-assembly/src/main/dist/NOTICE 
> 83d0f3313a01881c9c651077036c17f962cd38b9 
>   geode-pulse/build.gradle 94f26f7a4106ea085ba1bc9a7001967f6b47a863 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CDL.java 
> 6243f8f599342dbdf00d3b541dfeca9da5def508 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/Cookie.java
>  1a0fa6fb7c1edd8b81bd4513ea6786a8ba4ba59c 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CookieList.java
>  99498f500fec9d85a30b610564c706731a55ed68 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTP.java
>  234d2bddc483f71503f84886be949f2b93a7ddd6 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTPTokener.java
>  09b68d872f492f65cff14a02997dbae657027992 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONArray.java
>  0db27363e51eaa4e7d40724ea82ed29975df46c4 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONException.java
>  fbd8866cd59817b588b84ae3bceb6e39f49fa8e2 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONML.java
>  fc19ca549da14441c8895bce56d46bf880b13c90 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONObject.java
>  13f2ccad8c24a346ef8eb20cd195f5bf53211eeb 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONString.java
>  45585c75dbe5c0dd50359117713e078263dfb7b3 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONStringer.java
>  8c5ff0826d5f6ad998d39ee73ef4a255e5fc0423 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONTokener.java
>  0f4b7ee8f017c1f561f954dab1e409236d382bf2 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONWriter.java
>  dea900ab240b9a1b25079dec43c1e775e7caef76 
>   geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/README 
> 2d7cdcf8a0ccdd29e0b1a3337da4338a51649bce 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XML.java 
> 25675f89b6d2e22fced09dd366b18753f28b3ab7 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XMLTokener.java
>  ff81731e11b49b649b92580fd169440c734a1006 
>   geode-pulse/src/main/webapp/META-INF/NOTICE 
> 706eda265cf0b54c73d01df85c0a79bde9082d8a 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/BaseServiceTest.java
>  ccc147d1533142d54c8c7378c935da8f5e3234f5 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionServiceTest.java
>  77e6dd89340c59f7c15363a1d878ca3b6165d90a 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionsMemberServiceTest.java
>  512cfc78e811a3234f170b243cf3983a96fc4788 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/MemberGatewayHubServiceTest.java
>  980a772a6a43a60befe3f4cec2c898b3e62ad038 
>   geode-web-api/src/main/webapp/META-INF/NOTICE 
> 21082b6de4fbd7ba4ec4bcb61e9e1bfda5ac162a 
>   geode-web/src/main/webapp/META-INF/NOTICE 
> 8c6e1d7faf3188599305f44c44318f6e6cfd00e6 
>   gradle/dependency-versions.properties 
> 828b0882d0813919e699d1ec83c7ba9c59f0220e 
> 
> Diff: https://reviews.apache.org/r/55280/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

[jira] [Commented] (GEODE-629) Replace use of org.json with Jackson JSON library

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-629:
-

These changes have been made since the above patch was posted:

{code}
commit 1b8a35734a7808623f0247ad5f82de92aea70c14
Author: Jens Deppe 
Date:   Fri Nov 6 08:53:25 2015 -0800

GEODE-533: GFSH query swaps row values when they are null

diff --git a/gemfire-json/src/main/java/org/json/JSONObject.java 
b/gemfire-json/src/main/java/org/json/JSONObject.java
index 63676cc..6c478db 100755
--- a/gemfire-json/src/main/java/org/json/JSONObject.java
+++ b/gemfire-json/src/main/java/org/json/JSONObject.java
@@ -999,6 +999,8 @@ public class JSONObject {
 Object result = method.invoke(bean, (Object[])null);
 if (result != null) {
 this.map.put(key, wrap(result));
+} else if (!method.getReturnType().isArray()) {
+this.map.put(key, JSONObject.NULL);
 }
 }
 }
{code}

{code}
commit 90e00bf97d4287f5462cf73eab2b5810c69c7077
Author: Jinmei Liao 
Date:   Thu Jul 28 09:11:56 2016 -0700

GEODE-1569: post process for serialized domain objects

* for client/server retreival, post process the value before it was put 
into the message
* for gfsh commands, post process the value before it was put into the 
command result json

diff --git a/geode-json/src/main/java/org/json/JSONObject.java 
b/geode-json/src/main/java/org/json/JSONObject.java
index 24f5cc7..a2c67a9 100755
--- a/geode-json/src/main/java/org/json/JSONObject.java
+++ b/geode-json/src/main/java/org/json/JSONObject.java
@@ -32,7 +32,6 @@ import java.lang.reflect.Method;
 import java.lang.reflect.Modifier;
 import java.util.Collection;
 import java.util.Enumeration;
-import java.util.HashSet;
 import java.util.Iterator;
 import java.util.LinkedHashMap;
 import java.util.Locale;
@@ -95,7 +94,6 @@ import java.util.Set;
  * @version 2012-05-29
  */
 public class JSONObject {
-
 /**
  * JSONObject.NULL is equivalent to the value that JavaScript calls null,
  * whilst Java's null is equivalent to the value that JavaScript calls
@@ -1481,9 +1479,8 @@ public class JSONObject {
  return object.toString();
  }
  
-if(cyclicDepChkEnabled.get() != null){  
-  if (cyclicDepChkEnabled.get()
-  && cyclicDependencySet.get().contains(object)) {
+if(cyclicDepChkEnabled.get()!=null && 
cyclicDependencySet.get()!=null){
+  if (cyclicDepChkEnabled.get() && 
cyclicDependencySet.get().contains(object)) {
 //break cyclic reference
 return object.getClass().getCanonicalName();
   }else {
{code}

> Replace use of org.json with Jackson JSON library
> -
>
> Key: GEODE-629
> URL: https://issues.apache.org/jira/browse/GEODE-629
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Jens Deppe
> Attachments: json.patch
>
>
> Currently we're using two different JSON libraries; org.json and jackson. We 
> have customized org.json in the module gemfire-json.
> We should try and consolidate on a single JSON library - namely jackson as it 
> is much more capable than org.json.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: copy files to servers

[Michael Stolz]

Does all this stuff get easier if we actually create a Spring Boot
application that embeds Geode server functionality?

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Fri, Jan 6, 2017 at 4:11 PM, John Blum  wrote:

> *@Anthony-*
>
> *> The server should be smart enough to figure out what's in my bundle and
> understand how to deploy it including any dependencies*
>
> Agreed on the dependencies part, but... "*smart enough to figure out what's
> in my bundle*".  Hmmm.  Beyond recognizing Geode/GemFire
> objects/interfaces, I don't see how this is likely.
>
> For instance, I recently added the ability (SGF-106
>  [1]) in SDG to create Indexes
> using
> Annotations on application domain objects/entities properties/fields when
> using the SDG mapping support
>  reference/html/#mapping>
> [2]
> (and SD *Repositories*).  Currently, Geode/GemFire does not even recognize
> SDG "defined" (annotated) Functions.  How is it going to know (or how I am
> I going tell it) about Index annotations now, or something else.  Of
> course, Geode/GemFire could delegate to the *Spring* container in both
> instances, but that does not cover cases where *Spring* is not used.
>
> [1] https://jira.spring.io/browse/SGF-106
> [2]
> http://docs.spring.io/spring-data-gemfire/docs/current/
> reference/html/#mapping
>
>
> On Fri, Jan 6, 2017 at 12:49 PM, Jacob Barrett 
> wrote:
>
> > We need to take a lesson from any modern Java application an embrace
> class
> > loader modularization. The only thing in the system class path should be
> > very minimal bootstrap jar. The rest of our needs should be addressed by
> > well organized and isolated class loaders.
> >
> > The deployment of a function, or set of functions, should operate in a
> > fully isolated class loader. The deployment should include all
> dependencies
> > except for the APIs provided by the Geode framework.
> >
> > -Jake
> >
> > On Fri, Jan 6, 2017 at 8:13 AM Michael Stolz  wrote:
> >
> > > So maybe a generic copy command is too insecure, I agree.
> > > What we should do is think about exactly what files we think we are
> > trying
> > > to deploy.
> > >
> > >1. I believe that there is a need to deploy dependency jars into the
> > >system classpath.
> > >2. I believe that there is also a desire to be able to deploy Spring
> > >Data Geode xml configuration files.
> > >3. There is also an issue with attempting to deploy Spring Data
> Geode
> > >functions that we should try to work out.
> > >
> > > Anything else that anyone is aware of?
> > >
> > >
> > >
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: 631-835-4771 <(631)%20835-4771>
> > >
> > > On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
> > > wrote:
> > >
> > > > Agree with Anthony. A copy command would either duplicate what deploy
> > > does
> > > > by only putting files within as specific location in the server's
> > > directory
> > > > or creating a security nightmare if allowed to write anywhere on the
> > > host.
> > > >
> > > >
> > > > On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
> > wrote:
> > > >
> > > > > I think there are lots of great OS orchestration and automation
> > tools.
> > > > > I’m not sure I understand the need for `gfsh cp`.  If I could
> easily
> > > grab
> > > > > the member hostnames from `gfsh list members` and pipe them into
> > mpssh
> > > > (for
> > > > > example) that would do the job.
> > > > >
> > > > > I *do* like the idea of an improved `gfsh deploy` that supports hot
> > > > deploy
> > > > > and reconfiguration.
> > > > >
> > > > > Anthony
> > > > >
> > > > > > On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar <
> sbawas...@pivotal.io
> > >
> > > > > wrote:
> > > > > >
> > > > > > Some application may need to copy files to all the servers. These
> > > files
> > > > > > could either be data files or they could be configuration files
> > > needed
> > > > by
> > > > > > the application or they could be jar files (that don't have
> > functions
> > > > but
> > > > > > have say, spring data geode jar files) that need to be on the
> > > server's
> > > > > > classpath.
> > > > > > We could accomplish this by enhancing the current gfsh "deploy"
> > > command
> > > > > to
> > > > > > accept any kind of file and write it to the servers file system
> OR
> > > > > create a
> > > > > > new gfsh "copy" command to copy any arbitrary file to the
> servers.
> > > > > > I would personally like to repurpose the deploy command but would
> > > like
> > > > to
> > > > > > hear the community's opinion.
> > > > > >
> > > > > > Thanks!
> > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

Re: copy files to servers

[John Blum]

@Dan-

`deploy resource` is like `deploy jar` today, but *without* the additional
steps of constructing/initializing and (possibly) registering GemFire
objects (which currently only handles Functions today).

The idea is, a user may not want the same objects applied to all
servers/nodes in the cluster, especially if all their application artifacts
and dependencies are all uploaded in 1 JAR (which is as it should be, but
technically, is an application developers design decision, IMO).

For instance, a Function does not (and perhaps, should not) necessarily be
deployed on every single node in the cluster.  And by "deploy" I really
mean "applied"; not whether the bits physically exists or not.  In fact,
the bits should exist on all nodes in case the user wants to deploy/apply
the Function, Listener, or whatever, to another existing, or possibly new
node in the cluster.

The same might be true of a Loader or Writer, though I don't recall whether
Geode may think the Region configuration conflicts in this case if all
nodes hosting the Region do not have the same Listeners, Loader and Writer
configured???.

Anyhow...  perhaps "deploy" is the wrong terminology as I did not mean that
each individual `deploy` command: `deploy function`, `deploy cache-listener`,
etc, "uploads" artifacts; NO, yuck!  Only `deploy resource`, or rather `upload
resource` would.

SIDE NOTE: We keep talking about containers as if they just handle class
loading or something.  That is not all that is required to be a container,
much less, a completely "managed" environment (which PCF has covered)!.
Class loading is an implementation detail.  It would have been easier if
containers just forked individual JVM processes, IMO (some do).  Spring XD
switched from class loading to individual JVM processes in SCDF. This class
loading business is highly error prone, and, well, overly complicated to
get right in all situations.

In addition, you cannot be a proper container without an SPI or extension
points to customize lifecycle, scope, events, etc, all the things
application components need in a managed environment.


On Fri, Jan 6, 2017 at 1:34 PM, Michael Stolz  wrote:

> Does all this stuff get easier if we actually create a Spring Boot
> application that embeds Geode server functionality?
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: 631-835-4771
>
> On Fri, Jan 6, 2017 at 4:11 PM, John Blum  wrote:
>
> > *@Anthony-*
> >
> > *> The server should be smart enough to figure out what's in my bundle
> and
> > understand how to deploy it including any dependencies*
> >
> > Agreed on the dependencies part, but... "*smart enough to figure out
> what's
> > in my bundle*".  Hmmm.  Beyond recognizing Geode/GemFire
> > objects/interfaces, I don't see how this is likely.
> >
> > For instance, I recently added the ability (SGF-106
> >  [1]) in SDG to create Indexes
> > using
> > Annotations on application domain objects/entities properties/fields when
> > using the SDG mapping support
> >  > reference/html/#mapping>
> > [2]
> > (and SD *Repositories*).  Currently, Geode/GemFire does not even
> recognize
> > SDG "defined" (annotated) Functions.  How is it going to know (or how I
> am
> > I going tell it) about Index annotations now, or something else.  Of
> > course, Geode/GemFire could delegate to the *Spring* container in both
> > instances, but that does not cover cases where *Spring* is not used.
> >
> > [1] https://jira.spring.io/browse/SGF-106
> > [2]
> > http://docs.spring.io/spring-data-gemfire/docs/current/
> > reference/html/#mapping
> >
> >
> > On Fri, Jan 6, 2017 at 12:49 PM, Jacob Barrett 
> > wrote:
> >
> > > We need to take a lesson from any modern Java application an embrace
> > class
> > > loader modularization. The only thing in the system class path should
> be
> > > very minimal bootstrap jar. The rest of our needs should be addressed
> by
> > > well organized and isolated class loaders.
> > >
> > > The deployment of a function, or set of functions, should operate in a
> > > fully isolated class loader. The deployment should include all
> > dependencies
> > > except for the APIs provided by the Geode framework.
> > >
> > > -Jake
> > >
> > > On Fri, Jan 6, 2017 at 8:13 AM Michael Stolz 
> wrote:
> > >
> > > > So maybe a generic copy command is too insecure, I agree.
> > > > What we should do is think about exactly what files we think we are
> > > trying
> > > > to deploy.
> > > >
> > > >1. I believe that there is a need to deploy dependency jars into
> the
> > > >system classpath.
> > > >2. I believe that there is also a desire to be able to deploy
> Spring
> > > >Data Geode xml configuration files.
> > > >3. There is also an issue with attempting to deploy Spring Data
> > Geode
> > > >functions that we should try to work out.
> > > >
> > > > Anything else that anyone is aware of?
> > > >
> > 

Re: Review Request 55236: GEODE-2271 Reduce pdx type id generation for string fields in JSON

[Bruce Schuchardt]

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




geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java (line 
906)


It looks like this creates a PdxString if the field is NULL or NULL_STRING. 
 Is that the correct thing to do?  I would think that DSCODE_NULL, at least, 
would return a null.



geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java (line 
159)


Use an assertion:
assertEquals(PdxInstance.class, receivedObject.getClass());



geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java (line 
178)


How about using assertions instead of these if/else statements?  The 
if/else doesn't give you as much information about a failure as an assertion.

assertEquals(TestObjectForJSONFormatter.class, actualTestObject.getClass());
assertEquals(expectedTestObject, actualTestObject);


- Bruce Schuchardt


On Jan. 6, 2017, 7:30 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55236/
> ---
> 
> (Updated Jan. 6, 2017, 7:30 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2271 JSOnFormatter can generate three pdxTypeId for one json field.
> 
> JSON field can have 3 values(fieldValue, NULL, fieldNotExist), this
> causes 3 pdxTypeIds. To reuduce this we merged first two values in 
> one pdxType.
> 
> Added unit test for it
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/pdx/JSONFormatter.java ff2ce04 
>   geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java 
> 4ebc33d 
>   
> geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceHelper.java
>  e957cd6 
>   geode-core/src/test/java/org/apache/geode/pdx/Employee.java cfb46b5 
>   geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java 
> 979da13 
>   geode-core/src/test/java/org/apache/geode/pdx/PdxStringJUnitTest.java 
> c072e14 
>   
> geode-core/src/test/java/org/apache/geode/pdx/TestObjectForJSONFormatter.java 
> ca0abc3 
> 
> Diff: https://reviews.apache.org/r/55236/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: Review Request 55236: GEODE-2271 Reduce pdx type id generation for string fields in JSON

[Hitesh Khamesra]

> On Jan. 6, 2017, 4 p.m., Udo Kohlmeyer wrote:
> > geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java, 
> > lines 881-885
> > 
> >
> > How does this affect the "rest" of the system and the processing of 
> > PDX? Have we now impacted performance?

This should be fine.


> On Jan. 6, 2017, 4 p.m., Udo Kohlmeyer wrote:
> > geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java, 
> > line 266
> > 
> >
> > Maybe we need a test that confirms that we will only generate 2 type 
> > definitions. One where the field exists and one where the field does not 
> > exist

That the way pdx works. But I added null check test as well


- Hitesh


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


On Jan. 6, 2017, 7:30 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55236/
> ---
> 
> (Updated Jan. 6, 2017, 7:30 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2271 JSOnFormatter can generate three pdxTypeId for one json field.
> 
> JSON field can have 3 values(fieldValue, NULL, fieldNotExist), this
> causes 3 pdxTypeIds. To reuduce this we merged first two values in 
> one pdxType.
> 
> Added unit test for it
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/pdx/JSONFormatter.java ff2ce04 
>   geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java 
> 4ebc33d 
>   
> geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceHelper.java
>  e957cd6 
>   geode-core/src/test/java/org/apache/geode/pdx/Employee.java cfb46b5 
>   geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java 
> 979da13 
>   geode-core/src/test/java/org/apache/geode/pdx/PdxStringJUnitTest.java 
> c072e14 
>   
> geode-core/src/test/java/org/apache/geode/pdx/TestObjectForJSONFormatter.java 
> ca0abc3 
> 
> Diff: https://reviews.apache.org/r/55236/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: Review Request 55236: GEODE-2271 Reduce pdx type id generation for string fields in JSON

[Hitesh Khamesra]

> On Jan. 6, 2017, 9:42 p.m., Bruce Schuchardt wrote:
> > geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java, 
> > line 906
> > 
> >
> > It looks like this creates a PdxString if the field is NULL or 
> > NULL_STRING.  Is that the correct thing to do?  I would think that 
> > DSCODE_NULL, at least, would return a null.

No, it should return null. i will revert it back. Thanks


- Hitesh


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


On Jan. 6, 2017, 7:30 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55236/
> ---
> 
> (Updated Jan. 6, 2017, 7:30 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2271 JSOnFormatter can generate three pdxTypeId for one json field.
> 
> JSON field can have 3 values(fieldValue, NULL, fieldNotExist), this
> causes 3 pdxTypeIds. To reuduce this we merged first two values in 
> one pdxType.
> 
> Added unit test for it
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/pdx/JSONFormatter.java ff2ce04 
>   geode-core/src/main/java/org/apache/geode/pdx/internal/PdxReaderImpl.java 
> 4ebc33d 
>   
> geode-core/src/main/java/org/apache/geode/pdx/internal/json/PdxInstanceHelper.java
>  e957cd6 
>   geode-core/src/test/java/org/apache/geode/pdx/Employee.java cfb46b5 
>   geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java 
> 979da13 
>   geode-core/src/test/java/org/apache/geode/pdx/PdxStringJUnitTest.java 
> c072e14 
>   
> geode-core/src/test/java/org/apache/geode/pdx/TestObjectForJSONFormatter.java 
> ca0abc3 
> 
> Diff: https://reviews.apache.org/r/55236/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

[jira] [Commented] (GEODE-2260) Move geode examples to new repo home

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-examples/pull/1

GEODE-2260: Revise geode-examples to be in their own repo

- Revise build to add rat check and spotless task
- Add Apache license to README.md files
- Apply spotless format changes
- Add .gitignore
- Revise paths in README.md instructions

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

$ git pull https://github.com/karensmolermiller/geode-examples 
feature/GEODE-2260

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

https://github.com/apache/geode-examples/pull/1.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 #1


commit 6b7eacb2bfb196b1aa390695445c6e8a28071d16
Author: Karen Miller 
Date:   2017-01-05T21:45:30Z

GEODE-2260: Revise geode-examples to be in their own repo

- Revise build to add rat check and spotless task
- Add Apache license to README.md files
- Apply spotless format changes
- Add .gitignore
- Revise paths in README.md instructions




> Move geode examples to new repo home
> 
>
> Key: GEODE-2260
> URL: https://issues.apache.org/jira/browse/GEODE-2260
> Project: Geode
>  Issue Type: New Feature
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Initialize new repository (https://github.com/apache/geode-examples) for 
> geode-examples module.
> Move current geode-examples module to the new repo.
> Revise instructions to work outside the geode repo. Verify the replicated 
> example works once moved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode-examples pull request #1: GEODE-2260: Revise geode-examples to be in t...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-examples/pull/1

GEODE-2260: Revise geode-examples to be in their own repo

- Revise build to add rat check and spotless task
- Add Apache license to README.md files
- Apply spotless format changes
- Add .gitignore
- Revise paths in README.md instructions

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

$ git pull https://github.com/karensmolermiller/geode-examples 
feature/GEODE-2260

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

https://github.com/apache/geode-examples/pull/1.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 #1


commit 6b7eacb2bfb196b1aa390695445c6e8a28071d16
Author: Karen Miller 
Date:   2017-01-05T21:45:30Z

GEODE-2260: Revise geode-examples to be in their own repo

- Revise build to add rat check and spotless task
- Add Apache license to README.md files
- Apply spotless format changes
- Add .gitignore
- Revise paths in README.md instructions




---
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: [jira] [Commented] (GEODE-2260) Move geode examples to new repo home

[Karen Miller]

I'd appreciate reviews on this PR from Dan S, Swapnil B, Mark B, and Dave
B.,
along with anyone else who is interested in improving the new geode
examples.
Thanks.

On Fri, Jan 6, 2017 at 1:47 PM, ASF GitHub Bot (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/GEODE-2260?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=15805871#comment-15805871 ]
>
> ASF GitHub Bot commented on GEODE-2260:
> ---
>
> GitHub user karensmolermiller opened a pull request:
>
> https://github.com/apache/geode-examples/pull/1
>
> GEODE-2260: Revise geode-examples to be in their own repo
>
> - Revise build to add rat check and spotless task
> - Add Apache license to README.md files
> - Apply spotless format changes
> - Add .gitignore
> - Revise paths in README.md instructions
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/karensmolermiller/geode-examples
> feature/GEODE-2260
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/geode-examples/pull/1.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 #1
>
> 
> commit 6b7eacb2bfb196b1aa390695445c6e8a28071d16
> Author: Karen Miller 
> Date:   2017-01-05T21:45:30Z
>
> GEODE-2260: Revise geode-examples to be in their own repo
>
> - Revise build to add rat check and spotless task
> - Add Apache license to README.md files
> - Apply spotless format changes
> - Add .gitignore
> - Revise paths in README.md instructions
>
> 
>
>
> > Move geode examples to new repo home
> > 
> >
> > Key: GEODE-2260
> > URL: https://issues.apache.org/jira/browse/GEODE-2260
> > Project: Geode
> >  Issue Type: New Feature
> >Reporter: Karen Smoler Miller
> >Assignee: Karen Smoler Miller
> >
> > Initialize new repository (https://github.com/apache/geode-examples)
> for geode-examples module.
> > Move current geode-examples module to the new repo.
> > Revise instructions to work outside the geode repo. Verify the
> replicated example works once moved.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: copy files to servers

[John Blum]

@Mike-

*> Does all this stuff get easier if we actually create a Spring
Boot application that embeds Geode server functionality?*

This is a loaded question.  At development-time, yes, much easier, I
think.  You can even leverage *Spring Boot* DevTools

[1]
(for examle

 [2]).

If Geode is a separate service (as is the case in PCF), then not really.
You still have the same problems, i.e. how to keep your application in-sync
with your "external" services, which might also share or need the same
dependencies.  But then, to be fair, *Spring Boot* apps are typically
deployed as "cache clients" consuming a separate Geode/GemFire service
(i.e. the traditional client/server approach).

It's just easier to configure, bootstrap and deploy a *Spring Boot*
application (that uses *Spring* config), which might also happen to be a
peer (embedded Geode/GemFire UC).  An app is a single, self-contained,
testable, and deployable unit, and "currency" in a cloud environment.

I can scale it up or down by initiating more instances of my app.  These
apps can form a Geode/GemFire cluster, even within a managed environment,
that is all architected/organized from the perspective of the app.  This
moves you closer to a pure microservices model, where each individual
app/service technically has it's own data store.  Though in our hybrid,
mutated model our apps would share the data store since all the same *Spring
Boot* apps would/could form a cluster in Geode/GemFire.  One advantage of
this hybrid approach is you achieve strong consistency along with
availability in a highly distributed manner, where the pure microservices
approach emphases availability over consistency.

We don't pitch/recommend this approach in practice, TMK.  There are
certainly tradeoffs, particularly if you thing about JVM heap, or what it
actually means for an app to be a member in the cluster, subject to all the
responsibilities and consequences that come with it.

-John


[1]
http://docs.spring.io/spring-boot/docs/1.4.3.RELEASE/reference/htmlsingle/#using-boot-devtools
[2]
http://docs.spring.io/spring-boot/docs/1.4.3.RELEASE/reference/htmlsingle/#howto-reload-java-classes-without-restarting


On Fri, Jan 6, 2017 at 1:41 PM, John Blum  wrote:

> @Dan-
>
> `deploy resource` is like `deploy jar` today, but *without* the
> additional steps of constructing/initializing and (possibly) registering
> GemFire objects (which currently only handles Functions today).
>
> The idea is, a user may not want the same objects applied to all
> servers/nodes in the cluster, especially if all their application artifacts
> and dependencies are all uploaded in 1 JAR (which is as it should be, but
> technically, is an application developers design decision, IMO).
>
> For instance, a Function does not (and perhaps, should not) necessarily be
> deployed on every single node in the cluster.  And by "deploy" I really
> mean "applied"; not whether the bits physically exists or not.  In fact,
> the bits should exist on all nodes in case the user wants to deploy/apply
> the Function, Listener, or whatever, to another existing, or possibly new
> node in the cluster.
>
> The same might be true of a Loader or Writer, though I don't recall
> whether Geode may think the Region configuration conflicts in this case if
> all nodes hosting the Region do not have the same Listeners, Loader and
> Writer configured???.
>
> Anyhow...  perhaps "deploy" is the wrong terminology as I did not mean
> that each individual `deploy` command: `deploy function`, `deploy
> cache-listener`, etc, "uploads" artifacts; NO, yuck!  Only `deploy
> resource`, or rather `upload resource` would.
>
> SIDE NOTE: We keep talking about containers as if they just handle class
> loading or something.  That is not all that is required to be a container,
> much less, a completely "managed" environment (which PCF has covered)!.
> Class loading is an implementation detail.  It would have been easier if
> containers just forked individual JVM processes, IMO (some do).  Spring XD
> switched from class loading to individual JVM processes in SCDF. This class
> loading business is highly error prone, and, well, overly complicated to
> get right in all situations.
>
> In addition, you cannot be a proper container without an SPI or extension
> points to customize lifecycle, scope, events, etc, all the things
> application components need in a managed environment.
>
>
> On Fri, Jan 6, 2017 at 1:34 PM, Michael Stolz  wrote:
>
>> Does all this stuff get easier if we actually create a Spring Boot
>> application that embeds Geode server functionality?
>>
>> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Manager
>> Mobile: 631-835-4771
>>
>> On Fri, Jan 6, 2017 at 4:11 PM, John Blum  wrote:
>>
>> > *@Anthony-*
>> >
>> > *

[jira] [Assigned] (GEODE-2280) Lucene indexes are not working with PR accessors

[Dan Smith (JIRA)]

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

Dan Smith reassigned GEODE-2280:


Assignee: Dan Smith

> Lucene indexes are not working with PR accessors
> 
>
> Key: GEODE-2280
> URL: https://issues.apache.org/jira/browse/GEODE-2280
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
>Assignee: Dan Smith
>
> I discovered that if you try to create a system with lucene indexes and 
> partitioned region accessors, you get this error if you define the index on 
> the accessor
> {noformat}
> java.lang.IllegalStateException: The data region to create lucene index 
> should be with storage
>   at 
> org.apache.geode.cache.lucene.internal.LuceneIndexForPartitionedRegion.createRepositoryManager(LuceneIndexForPartitionedRegion.java:63)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneIndexImpl.initialize(LuceneIndexImpl.java:165)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.afterDataRegionCreated(LuceneServiceImpl.java:214)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl$1.afterCreate(LuceneServiceImpl.java:194)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.invokeRegionAfter(GemFireCacheImpl.java:3374)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3353)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3194)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3182)
>   at parReg.ParRegUtil.createRegionProgrammatically(ParRegUtil.java:1223)
>   at parReg.ParRegUtil.createRegion(ParRegUtil.java:1184)
>   at parReg.ParRegTest.initializeRegion(ParRegTest.java:604)
>   at 
> parReg.ParRegTest.HydraTask_HA_initializeAccessor(ParRegTest.java:423)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at hydra.MethExecutor.execute(MethExecutor.java:182)
>   at hydra.MethExecutor.execute(MethExecutor.java:150)
>   at hydra.TestTask.execute(TestTask.java:192)
>   at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
> {noformat}
> If you *don't* define the index on the accessor, you get this error instead
> {noformat}
> Caused by: 
> org.apache.geode.internal.cache.wan.GatewaySenderConfigurationException: 
> Region region has [index#_region] AsyncEvent queue IDs. Another cache has 
> same region with [] AsyncEvent queue IDs. For region across all members, 
> AsyncEvent queue IDs should be same.
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.PartitionedRegion.checkSameSenderIdsAvailableOnAllNodes(PartitionedRegion.java:1145)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.LocalRegion.notifyGatewaySender(LocalRegion.java:6350)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.BucketRegion.notifyGatewaySender(BucketRegion.java:652)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5910)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.BucketRegion.basicPutPart2(BucketRegion.java:643)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2800)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:485)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1207)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1190)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.PartitionedRegionDataView.putEntryOnRemote(PartitionedRegionDataView.java:99)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.partitioned.PutMessage.operateOnPartitionedRegion(PutMessage.java:747)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:342)
>   at Remote Member '172.16.115.241(45136):32770' in 
> org.apache.geode.distribute

[jira] [Created] (GEODE-2280) Lucene indexes are not working with PR accessors

[Dan Smith (JIRA)]

Dan Smith created GEODE-2280:


 Summary: Lucene indexes are not working with PR accessors
 Key: GEODE-2280
 URL: https://issues.apache.org/jira/browse/GEODE-2280
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Dan Smith


I discovered that if you try to create a system with lucene indexes and 
partitioned region accessors, you get this error if you define the index on the 
accessor

{noformat}
java.lang.IllegalStateException: The data region to create lucene index should 
be with storage
at 
org.apache.geode.cache.lucene.internal.LuceneIndexForPartitionedRegion.createRepositoryManager(LuceneIndexForPartitionedRegion.java:63)
at 
org.apache.geode.cache.lucene.internal.LuceneIndexImpl.initialize(LuceneIndexImpl.java:165)
at 
org.apache.geode.cache.lucene.internal.LuceneServiceImpl.afterDataRegionCreated(LuceneServiceImpl.java:214)
at 
org.apache.geode.cache.lucene.internal.LuceneServiceImpl$1.afterCreate(LuceneServiceImpl.java:194)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.invokeRegionAfter(GemFireCacheImpl.java:3374)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3353)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3194)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3182)
at parReg.ParRegUtil.createRegionProgrammatically(ParRegUtil.java:1223)
at parReg.ParRegUtil.createRegion(ParRegUtil.java:1184)
at parReg.ParRegTest.initializeRegion(ParRegTest.java:604)
at 
parReg.ParRegTest.HydraTask_HA_initializeAccessor(ParRegTest.java:423)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hydra.MethExecutor.execute(MethExecutor.java:182)
at hydra.MethExecutor.execute(MethExecutor.java:150)
at hydra.TestTask.execute(TestTask.java:192)
at hydra.RemoteTestModule$1.run(RemoteTestModule.java:212)
{noformat}

If you *don't* define the index on the accessor, you get this error instead

{noformat}
Caused by: 
org.apache.geode.internal.cache.wan.GatewaySenderConfigurationException: Region 
region has [index#_region] AsyncEvent queue IDs. Another cache has same region 
with [] AsyncEvent queue IDs. For region across all members, AsyncEvent queue 
IDs should be same.
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.PartitionedRegion.checkSameSenderIdsAvailableOnAllNodes(PartitionedRegion.java:1145)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.LocalRegion.notifyGatewaySender(LocalRegion.java:6350)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.BucketRegion.notifyGatewaySender(BucketRegion.java:652)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5910)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.BucketRegion.basicPutPart2(BucketRegion.java:643)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2800)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:485)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1207)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1190)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.PartitionedRegionDataView.putEntryOnRemote(PartitionedRegionDataView.java:99)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.partitioned.PutMessage.operateOnPartitionedRegion(PutMessage.java:747)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:342)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at Remote Member '172.16.115.241(45136):32770' in 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
at Remote Member '172.16.115.241(45136):32770' in 
java.util.con

[jira] [Assigned] (GEODE-1343) Convert ManagementBase to JUnit 4

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-1343:


Assignee: Kirk Lund

> Convert ManagementBase to JUnit 4
> -
>
> Key: GEODE-1343
> URL: https://issues.apache.org/jira/browse/GEODE-1343
> Project: Geode
>  Issue Type: Task
>  Components: management
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>
> By converting to JUnit 4 we can start using other features such as Runners 
> and Parameterization



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-1027) MBeans should be initialized with current stats when they are created.

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-1027.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

> MBeans should be initialized with current stats when they are created.
> --
>
> Key: GEODE-1027
> URL: https://issues.apache.org/jira/browse/GEODE-1027
> Project: Geode
>  Issue Type: Improvement
>  Components: jmx
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Assignee: Kirk Lund
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-743) validate offline-disk-store failed in 8.1 regression run during cli.bt

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-743.
-
Resolution: Incomplete

Non-existent test

> validate offline-disk-store failed in 8.1 regression run during cli.bt
> --
>
> Key: GEODE-743
> URL: https://issues.apache.org/jira/browse/GEODE-743
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>
> {noformat}
> I am not sure whats causing this failure, but seems like the output for 
> validate diskstore was different when offline and online.
> In most of the test failures in this bt the CPU Active is almost clogged at 
> 100% so this machine is really being overloaded. 
> Also, this machine (w1-gst-dev17) has had some setup issues in the past. 
> But in-spite of above conditions I am opening a bug just to make sure that 
> this is getting looked at.
> Host name: w1-gst-dev17
> OS name: Windows Server 2008 R2
> Architecture: amd64
> OS version: 6.1
> Java version: 1.7.0_72
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: J:\where\jdk\1.7.0_72\x86_64.Windows_NT\jre
>   #
>   
>   GemFire Version 8.1.0
>   Source Date: 12/18/2014 16:07:30 PST
>   Source Revision: 50405
>   Source Repository: gemfire/branches/cedar_dev_Oct12
>   
>   Build Id: build 50405
>   Build Date: 12/18/2014 16:16:47 PST
>   Build Version: 8.1.0 build 50405 12/18/2014 16:16:47 PST javac 1.7.0_72
>   Build JDK: Java 1.7.0_72
>   Build Platform: Linux 2.6.32-220.23.1.el6.x86_64 i386
>   
>   #
> Test was run from 
> T:\gfe\81\Windows_NT\snapshots.50405\gf81cedarsancout\tests\classes\management/test/cli/cli.bt
> Test:
> management/test/cli/parReg/concParRegIncrementalCli.conf
>A=peer
>B=cli
>cliHosts=1
>cliThreadsPerVM=1
>cliVMsPerHost=1
>locatorHosts=1
>locatorThreadsPerVM=1
>locatorVMsPerHost=1
>peerHosts=5
>peerThreadsPerVM=5
>peerVMsPerHost=1
>redundantCopies=2
> No local.conf for this run
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1419021679980;
> *** Test failed with this error:
> CLIENT vm_13_thr_33_peer4_w1-gst-dev17_14948
> ENDTASK[9] util.PersistenceUtil.HydraTask_doOfflineValAndCompactionOnce
> ERROR util.TestException: Expected validate offline-disk-store 
> --name=diskStore1 
> --disk-dirs=H:\users\vbalaut\regrResults\cli\2014-12-19-07-29-17\concParRegIncrementalCli-1219-124110\vm_2_peer1_disk_1
>   output when offline to be the same as  when online, but they are different. 
> Offline results: Validating diskStore1
> [info 2014/12/19 12:59:58.849 PST  tid=0x1] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-743) validate offline-disk-store failed in 8.1 regression run during cli.bt

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-743.
---

> validate offline-disk-store failed in 8.1 regression run during cli.bt
> --
>
> Key: GEODE-743
> URL: https://issues.apache.org/jira/browse/GEODE-743
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>
> {noformat}
> I am not sure whats causing this failure, but seems like the output for 
> validate diskstore was different when offline and online.
> In most of the test failures in this bt the CPU Active is almost clogged at 
> 100% so this machine is really being overloaded. 
> Also, this machine (w1-gst-dev17) has had some setup issues in the past. 
> But in-spite of above conditions I am opening a bug just to make sure that 
> this is getting looked at.
> Host name: w1-gst-dev17
> OS name: Windows Server 2008 R2
> Architecture: amd64
> OS version: 6.1
> Java version: 1.7.0_72
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: J:\where\jdk\1.7.0_72\x86_64.Windows_NT\jre
>   #
>   
>   GemFire Version 8.1.0
>   Source Date: 12/18/2014 16:07:30 PST
>   Source Revision: 50405
>   Source Repository: gemfire/branches/cedar_dev_Oct12
>   
>   Build Id: build 50405
>   Build Date: 12/18/2014 16:16:47 PST
>   Build Version: 8.1.0 build 50405 12/18/2014 16:16:47 PST javac 1.7.0_72
>   Build JDK: Java 1.7.0_72
>   Build Platform: Linux 2.6.32-220.23.1.el6.x86_64 i386
>   
>   #
> Test was run from 
> T:\gfe\81\Windows_NT\snapshots.50405\gf81cedarsancout\tests\classes\management/test/cli/cli.bt
> Test:
> management/test/cli/parReg/concParRegIncrementalCli.conf
>A=peer
>B=cli
>cliHosts=1
>cliThreadsPerVM=1
>cliVMsPerHost=1
>locatorHosts=1
>locatorThreadsPerVM=1
>locatorVMsPerHost=1
>peerHosts=5
>peerThreadsPerVM=5
>peerVMsPerHost=1
>redundantCopies=2
> No local.conf for this run
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1419021679980;
> *** Test failed with this error:
> CLIENT vm_13_thr_33_peer4_w1-gst-dev17_14948
> ENDTASK[9] util.PersistenceUtil.HydraTask_doOfflineValAndCompactionOnce
> ERROR util.TestException: Expected validate offline-disk-store 
> --name=diskStore1 
> --disk-dirs=H:\users\vbalaut\regrResults\cli\2014-12-19-07-29-17\concParRegIncrementalCli-1219-124110\vm_2_peer1_disk_1
>   output when offline to be the same as  when online, but they are different. 
> Offline results: Validating diskStore1
> [info 2014/12/19 12:59:58.849 PST  tid=0x1] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2195) Hot Deploy of cluster configuration without bouncing the servers

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2195:
-
Labels: deploy  (was: )

> Hot Deploy of cluster configuration without bouncing the servers
> 
>
> Key: GEODE-2195
> URL: https://issues.apache.org/jira/browse/GEODE-2195
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: deploy
>
> user should be able to import a new set of cluster configuration without 
> having to shutdown all servers at least in the initial phases of trying out 
> cluster configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode-examples issue #1: GEODE-2260: Revise geode-examples to be in their ow...

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode-examples/pull/1
  
+1 - Ship it!


---
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] [Updated] (GEODE-1960) Provide protection against malicious developer jars deployed as functions

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1960:
-
Labels: deploy  (was: )

> Provide protection against malicious developer jars deployed as functions
> -
>
> Key: GEODE-1960
> URL: https://issues.apache.org/jira/browse/GEODE-1960
> Project: Geode
>  Issue Type: Improvement
>  Components: functions, security
>Reporter: Diane Hardman
>Priority: Minor
>  Labels: deploy
>
> Provide protection for functions that might contain malicious calls like 
> System.exit().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2260) Move geode examples to new repo home

[ASF GitHub Bot (JIRA)]

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

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

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode-examples/pull/1
  
+1 - Ship it!


> Move geode examples to new repo home
> 
>
> Key: GEODE-2260
> URL: https://issues.apache.org/jira/browse/GEODE-2260
> Project: Geode
>  Issue Type: New Feature
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Initialize new repository (https://github.com/apache/geode-examples) for 
> geode-examples module.
> Move current geode-examples module to the new repo.
> Revise instructions to work outside the geode repo. Verify the replicated 
> example works once moved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-881) gfsh deploy jars does not work when there are no servers

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-881:

Labels: deploy  (was: )

> gfsh deploy jars does not work when there are no servers
> 
>
> Key: GEODE-881
> URL: https://issues.apache.org/jira/browse/GEODE-881
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>  Labels: deploy
>
> After starting a locator but before starting any server, gfsh deploy jar 
> simply returns with {{No Members Found}} without storing the jars on the 
> locator. As a result when a server is started, it does not receive the jar 
> that was attempted to be deployed.
> This is problematic because, I am trying to start a server using cache-xml 
> that defines a PartitionResolver see GEODE-878. If the jar containing the 
> PartitionResolver is not deployed, the server won't start (gets a 
> ClassNotFound). If no server is running, I cannot deploy a jar.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-1951) users should be able to deploy jars when no servers are running

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1951:
-
Labels: deploy  (was: )

> users should be able to deploy jars when no servers are running
> ---
>
> Key: GEODE-1951
> URL: https://issues.apache.org/jira/browse/GEODE-1951
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Swapnil Bawaskar
>  Labels: deploy
>
> If I start a locator and then try to deploy a jar file I get the following 
> error message:
> {noformat}
> gfsh>deploy --jar=/path/to/some.jar
> No Members Found
> {noformat}
> The behavior desired is that the locator should store the jar file, so that 
> when members are started they can get this jar from the locator (through 
> cluster configuration). This behavior is desired for adding security 
> callbacks to the servers, as they are being started.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-1951) users should be able to deploy jars when no servers are running

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-1951.


> users should be able to deploy jars when no servers are running
> ---
>
> Key: GEODE-1951
> URL: https://issues.apache.org/jira/browse/GEODE-1951
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Swapnil Bawaskar
>  Labels: deploy
>
> If I start a locator and then try to deploy a jar file I get the following 
> error message:
> {noformat}
> gfsh>deploy --jar=/path/to/some.jar
> No Members Found
> {noformat}
> The behavior desired is that the locator should store the jar file, so that 
> when members are started they can get this jar from the locator (through 
> cluster configuration). This behavior is desired for adding security 
> callbacks to the servers, as they are being started.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-1951) users should be able to deploy jars when no servers are running

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-1951.
--
Resolution: Duplicate

This is a duplicate of GEODE-881

> users should be able to deploy jars when no servers are running
> ---
>
> Key: GEODE-1951
> URL: https://issues.apache.org/jira/browse/GEODE-1951
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Swapnil Bawaskar
>  Labels: deploy
>
> If I start a locator and then try to deploy a jar file I get the following 
> error message:
> {noformat}
> gfsh>deploy --jar=/path/to/some.jar
> No Members Found
> {noformat}
> The behavior desired is that the locator should store the jar file, so that 
> when members are started they can get this jar from the locator (through 
> cluster configuration). This behavior is desired for adding security 
> callbacks to the servers, as they are being started.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2199) deploy/undeploy should continue even if there is no running servers in the cluster

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2199:
-
Labels: DeployCommand deploy  (was: )

> deploy/undeploy should continue even if there is no running servers in the 
> cluster
> --
>
> Key: GEODE-2199
> URL: https://issues.apache.org/jira/browse/GEODE-2199
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: DeployCommand, deploy
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2195) Hot Deploy of cluster configuration without bouncing the servers

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2195:
-
Labels: DeployCommand deploy  (was: deploy)

> Hot Deploy of cluster configuration without bouncing the servers
> 
>
> Key: GEODE-2195
> URL: https://issues.apache.org/jira/browse/GEODE-2195
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: DeployCommand, deploy
>
> user should be able to import a new set of cluster configuration without 
> having to shutdown all servers at least in the initial phases of trying out 
> cluster configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-1960) Provide protection against malicious developer jars deployed as functions

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1960:
-
Labels: ClassLoader DeployCommand deploy  (was: DeployCommand deploy)

> Provide protection against malicious developer jars deployed as functions
> -
>
> Key: GEODE-1960
> URL: https://issues.apache.org/jira/browse/GEODE-1960
> Project: Geode
>  Issue Type: Improvement
>  Components: functions, security
>Reporter: Diane Hardman
>Priority: Minor
>  Labels: ClassLoader, DeployCommand, deploy
>
> Provide protection for functions that might contain malicious calls like 
> System.exit().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-1960) Provide protection against malicious developer jars deployed as functions

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1960:
-
Labels: DeployCommand deploy  (was: deploy)

> Provide protection against malicious developer jars deployed as functions
> -
>
> Key: GEODE-1960
> URL: https://issues.apache.org/jira/browse/GEODE-1960
> Project: Geode
>  Issue Type: Improvement
>  Components: functions, security
>Reporter: Diane Hardman
>Priority: Minor
>  Labels: DeployCommand, deploy
>
> Provide protection for functions that might contain malicious calls like 
> System.exit().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-800) Geode's classloading mechanism is unable to resolve classes found within nested jars

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-800:

Labels: ClassLoader DeployCommand deploy  (was: )

> Geode's classloading mechanism is unable to resolve classes found within 
> nested jars
> 
>
> Key: GEODE-800
> URL: https://issues.apache.org/jira/browse/GEODE-800
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Reporter: Jens Deppe
>  Labels: ClassLoader, DeployCommand, deploy
>
> This issue is particularly evident when using Geode in a Spring Boot app 
> which creates an 'über' jar containing all dependent jars.
> When Geode is launched in this context, the following errors can be seen:
> {noformat}
> [warn 2016/01/20 08:53:29.431 PST  tid=0xd] (tid=13 msgId=0) Required 
> Commands classes were not loaded. Check logs for errors.
> java.lang.IllegalStateException: Required Commands classes were not loaded. 
> Check logs for errors.
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.raiseExceptionIfEmpty(CommandManager.java:249)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.loadCommands(CommandManager.java:188)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.(CommandManager.java:86)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:278)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:258)
> at 
> com.gemstone.gemfire.management.internal.cli.remote.CommandProcessor.(CommandProcessor.java:58)
> ...
> {noformat}
> The problem here is in {{ClasspathScanLoadHelper.getClasses()}}. In this 
> method we call:
> {noformat}
> Enumeration resources = 
> ClassPathLoader.getLatest().getResources(packagePath);
> {noformat}
> However {{getResources()}} doesn't just work against the 'latest' 
> classloader, but also considers the thread context classloader. In the case 
> of a Spring Boot app, Spring does provide such a classloader and 
> {{getResources}} is able to find the necessary resources {{CommandMarker}} 
> classes. (These classes are found within a nested jar. For ex. 
> {{jar:file:/Users/jdeppe/src/woddrive/WodDrive-GF-Server/target/WodDriveGFServer.jar!/lib/gemfire-core-1.0.0-incubating-SNAPSHOT.jar!/com/gemstone/gemfire/management/internal/cli/commands}}).
>  This is all fine, but subsequent code doesn't consider classes (or packages) 
> within nested jars, and in addition, when classes actually get resolved, the 
> thread context classloader (where those resources might have come from) is 
> not considered.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-1956) CI failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1956:


Commit 639c856021ec9321cdc0895a5e1503a6296dc765 in geode's branch 
refs/heads/feature/GEODE-523 from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=639c856 ]

Revert "GEODE-1956: fix the race condition that cause the vm only hosts 1 
primary bucket"

This reverts commit c3162e0b9d7315c4665ebd05e26515228f9e89de.


> CI failure: 
> LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate
> -
>
> Key: GEODE-1956
> URL: https://issues.apache.org/jira/browse/GEODE-1956
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Bruce Schuchardt
>Assignee: xiaojian zhou
>  Labels: CI
> Fix For: 1.1.0
>
>
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$50/1718051859.run
>  in VM 0 running on Host cc2-rh6.gemstone.com with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:389)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:293)
>   at 
> org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate(LuceneQueriesPeerPRRedundancyDUnitTest.java:80)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.proc

[jira] [Commented] (GEODE-523) PartitionListener requires tests and clean up

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-523:
---

Commit fa52bd575fc4ac7d83d328310790eb395232384c in geode's branch 
refs/heads/feature/GEODE-523 from [~sboorlagadda]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fa52bd5 ]

Merge branch 'master' into feature/GEODE-523


> PartitionListener requires tests and clean up
> -
>
> Key: GEODE-523
> URL: https://issues.apache.org/jira/browse/GEODE-523
> Project: Geode
>  Issue Type: Test
>  Components: regions
>Reporter: Kirk Lund
>Assignee: Sai Boorlagadda
>
> Many users are using PartitionListener. This API requires tests, proper 
> javadocs and general cleanup.
> See GEODE-390 and GEODE-72



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-800) Geode's classloading mechanism is unable to resolve classes found within nested jars

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-800:

Affects Version/s: 1.0.0-incubating

> Geode's classloading mechanism is unable to resolve classes found within 
> nested jars
> 
>
> Key: GEODE-800
> URL: https://issues.apache.org/jira/browse/GEODE-800
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>  Labels: ClassLoader, DeployCommand, deploy
>
> This issue is particularly evident when using Geode in a Spring Boot app 
> which creates an 'über' jar containing all dependent jars.
> When Geode is launched in this context, the following errors can be seen:
> {noformat}
> [warn 2016/01/20 08:53:29.431 PST  tid=0xd] (tid=13 msgId=0) Required 
> Commands classes were not loaded. Check logs for errors.
> java.lang.IllegalStateException: Required Commands classes were not loaded. 
> Check logs for errors.
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.raiseExceptionIfEmpty(CommandManager.java:249)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.loadCommands(CommandManager.java:188)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.(CommandManager.java:86)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:278)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:258)
> at 
> com.gemstone.gemfire.management.internal.cli.remote.CommandProcessor.(CommandProcessor.java:58)
> ...
> {noformat}
> The problem here is in {{ClasspathScanLoadHelper.getClasses()}}. In this 
> method we call:
> {noformat}
> Enumeration resources = 
> ClassPathLoader.getLatest().getResources(packagePath);
> {noformat}
> However {{getResources()}} doesn't just work against the 'latest' 
> classloader, but also considers the thread context classloader. In the case 
> of a Spring Boot app, Spring does provide such a classloader and 
> {{getResources}} is able to find the necessary resources {{CommandMarker}} 
> classes. (These classes are found within a nested jar. For ex. 
> {{jar:file:/Users/jdeppe/src/woddrive/WodDrive-GF-Server/target/WodDriveGFServer.jar!/lib/gemfire-core-1.0.0-incubating-SNAPSHOT.jar!/com/gemstone/gemfire/management/internal/cli/commands}}).
>  This is all fine, but subsequent code doesn't consider classes (or packages) 
> within nested jars, and in addition, when classes actually get resolved, the 
> thread context classloader (where those resources might have come from) is 
> not considered.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode-examples issue #1: GEODE-2260: Revise geode-examples to be in their ow...

[scmbuildguy]

Github user scmbuildguy commented on the issue:

https://github.com/apache/geode-examples/pull/1
  
+1


---
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-1956) CI failure: LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1956:


Commit c3162e0b9d7315c4665ebd05e26515228f9e89de in geode's branch 
refs/heads/feature/GEODE-523 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c3162e0 ]

GEODE-1956: fix the race condition that cause the vm only hosts 1 primary bucket


> CI failure: 
> LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate
> -
>
> Key: GEODE-1956
> URL: https://issues.apache.org/jira/browse/GEODE-1956
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Bruce Schuchardt
>Assignee: xiaojian zhou
>  Labels: CI
> Fix For: 1.1.0
>
>
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$50/1718051859.run
>  in VM 0 running on Host cc2-rh6.gemstone.com with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:389)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:293)
>   at 
> org.apache.geode.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnIndexUpdate(LuceneQueriesPeerPRRedundancyDUnitTest.java:80)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAcce

[jira] [Commented] (GEODE-2260) Move geode examples to new repo home

[ASF GitHub Bot (JIRA)]

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

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

Github user scmbuildguy commented on the issue:

https://github.com/apache/geode-examples/pull/1
  
+1


> Move geode examples to new repo home
> 
>
> Key: GEODE-2260
> URL: https://issues.apache.org/jira/browse/GEODE-2260
> Project: Geode
>  Issue Type: New Feature
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Initialize new repository (https://github.com/apache/geode-examples) for 
> geode-examples module.
> Move current geode-examples module to the new repo.
> Revise instructions to work outside the geode repo. Verify the replicated 
> example works once moved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 55286: GEODE-2280: Allow accessors to create a lucene index

[Dan Smith]

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

Review request for geode, Barry Oglesby and Jason Huynh.


Repository: geode


Description
---

Allow peer accessors to create a lucene index and fixing the dunit tests
to actually use an accessor.


Diffs
-

  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 f8bbc418955b7fb6102312325f0304cd385a0a7c 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPRBase.java
 8e62c85896da8bef5684c71cda8dc13624feede4 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPeerPRDUnitTest.java
 ffab354f1c1ea030267fa21f4efd477004b622c8 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPeerPROverflowDUnitTest.java
 b9aa0b781522e58ae6650e704e7ba4f9325ed99e 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPeerPRRedundancyDUnitTest.java
 d645d5e357b3312c5501ca24abff40ceeaf93682 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegionTest.java
 cec37343fe1b249cc767839a708229a6c9011881 

Diff: https://reviews.apache.org/r/55286/diff/


Testing
---


Thanks,

Dan Smith

Review Request 55288: GEODE-2261: do not use remote function calls to update the shared configuration

[Jinmei Liao]

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

Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.


Repository: geode


Description
---

GEODE-2261: do not use remote function calls to update the shared configuration


Diffs
-

  geode-core/src/main/java/org/apache/geode/distributed/internal/DM.java 
19381d4c951661b8581befc462044602c090cde2 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
 5ae54313eb16cf8613ca7dd884beb12c150a2b3b 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
 ec22b021675cd40d2a8383d13ede40fa757a2c6f 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
 6db641569449c6cf789ccd8013ae524b7c34bcff 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
 4eac4e9ea0e5660d2f9ec39af30c5ba7e6ab8ff5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
 358cdc1795b5597995f7bfafd7a589127476d5f5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
 7c887bee0a3346814b6961b4259ddbe668c1d4bd 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 505b6a830d986f367d267e543f2aa876e22c6470 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportSharedConfigurationCommands.java
 3a2d94975d4abf94348c9a18386956b4fe7c87a7 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
 adb03c6c301303e664c6e7bbdd658bb4cdd6bc84 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
 c5e9a4e26a790e20f14174fd3717db03f96dd697 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
 ebdae568492931643d6d4de68503985d3819854d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
 dd6a327132a74cd2c481883c9c23ccb6c2d2f5a1 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportSharedConfigurationFunction.java
 f20d9d444059e26b19f9468dbb07a0f10ab12e94 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
 beee3db4e41d7748ee7ebeaa07b68ef3c7386b96 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/LoadSharedConfigurationFunction.java
 c4fa6eeae319b52a90b90f3df37bbc00d9d2cfa9 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
 4ae1a1ca739ada17a33d554da856edf283e78b03 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/SharedConfigurationWriter.java
 2be9873abc0d66506a6b63d58f9c5ff1f792b12f 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/AddJarFunction.java
 b986372f462cbfa30f7fe615e5b219ccff9db5e9 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/AddXmlEntityFunction.java
 c562c9c1a9ea4213168560e30887d4f920d38f5a 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/DeleteJarFunction.java
 d0d36a86b810206d527b62cd6840c616fb26 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/DeleteXmlEntityFunction.java
 1138d5ff8b277304882bc867aa160cd718ff8bb2 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/ModifyXmlAndPropertiesFunction.java
 97b9ec9fc4065b8141ed63df08566fd00658 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/functions/UploadJarFunction.java
 7ea868264373cd83519f3bf1f9f21397569f3061 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/XmlUtils.java
 cad770c50efa442dc6cb95734819a77e9570cfeb 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/SharedConfigurationJUnitTest.java
 e3e5620610308a30552c14ee41ec607a979e6dcb 
  
geode-core/src/test/java/org/apache/geode/internal/cache/extension/mock/MockExtensionCommands.java
 e2a56fd8ce181b39d35f69db9ca191c28e43f7fe 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ConfigCommandsDUnitTest.java
 d86cb0be63caabb01179ed11b4015a3c3f172f32 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommandsDUnitTest.java
 7a75cfa7b402b921a2266a04ced9215428fe54b8 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
 7cf9a3a3fb6f58715919d8469365af6604352ef0 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommand

Re: Review Request 55280: GEODE-2142: Remove JSON from pulse

[Mark Bretl]

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


Ship it!




Will there be another changeset to remove the code from geode-json sub-project 
as well?

- Mark Bretl


On Jan. 6, 2017, 1:09 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55280/
> ---
> 
> (Updated Jan. 6, 2017, 1:09 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kirk Lund, and Mark Bretl.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2142: Add JSON usage to NOTICE 
> 
> GEODE-2142: Remove JSON dependency from pulse
> 
> Remove the Cat-X licensed JSON software from geode-pulse and replace
> it with the friendly open-json replacement.  See
> https://github.com/tdunning/open-json.
> 
> Update copyright date in NOTICE
> 
> 
> Diffs
> -
> 
>   NOTICE 4801b2aedf4f254c85cba9f27d2f99d2ca2e046b 
>   geode-assembly/src/main/dist/NOTICE 
> 83d0f3313a01881c9c651077036c17f962cd38b9 
>   geode-pulse/build.gradle 94f26f7a4106ea085ba1bc9a7001967f6b47a863 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CDL.java 
> 6243f8f599342dbdf00d3b541dfeca9da5def508 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/Cookie.java
>  1a0fa6fb7c1edd8b81bd4513ea6786a8ba4ba59c 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CookieList.java
>  99498f500fec9d85a30b610564c706731a55ed68 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTP.java
>  234d2bddc483f71503f84886be949f2b93a7ddd6 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTPTokener.java
>  09b68d872f492f65cff14a02997dbae657027992 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONArray.java
>  0db27363e51eaa4e7d40724ea82ed29975df46c4 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONException.java
>  fbd8866cd59817b588b84ae3bceb6e39f49fa8e2 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONML.java
>  fc19ca549da14441c8895bce56d46bf880b13c90 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONObject.java
>  13f2ccad8c24a346ef8eb20cd195f5bf53211eeb 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONString.java
>  45585c75dbe5c0dd50359117713e078263dfb7b3 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONStringer.java
>  8c5ff0826d5f6ad998d39ee73ef4a255e5fc0423 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONTokener.java
>  0f4b7ee8f017c1f561f954dab1e409236d382bf2 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONWriter.java
>  dea900ab240b9a1b25079dec43c1e775e7caef76 
>   geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/README 
> 2d7cdcf8a0ccdd29e0b1a3337da4338a51649bce 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XML.java 
> 25675f89b6d2e22fced09dd366b18753f28b3ab7 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XMLTokener.java
>  ff81731e11b49b649b92580fd169440c734a1006 
>   geode-pulse/src/main/webapp/META-INF/NOTICE 
> 706eda265cf0b54c73d01df85c0a79bde9082d8a 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/BaseServiceTest.java
>  ccc147d1533142d54c8c7378c935da8f5e3234f5 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionServiceTest.java
>  77e6dd89340c59f7c15363a1d878ca3b6165d90a 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionsMemberServiceTest.java
>  512cfc78e811a3234f170b243cf3983a96fc4788 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/MemberGatewayHubServiceTest.java
>  980a772a6a43a60befe3f4cec2c898b3e62ad038 
>   geode-web-api/src/main/webapp/META-INF/NOTICE 
> 21082b6de4fbd7ba4ec4bcb61e9e1bfda5ac162a 
>   geode-web/src/main/webapp/META-INF/NOTICE 
> 8c6e1d7faf3188599305f44c44318f6e6cfd00e6 
>   gradle/dependency-versions.properties 
> 828b0882d0813919e699d1ec83c7ba9c59f0220e 
> 
> Diff: https://reviews.apache.org/r/55280/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 55280: GEODE-2142: Remove JSON from pulse

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On Jan. 6, 2017, 9:09 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55280/
> ---
> 
> (Updated Jan. 6, 2017, 9:09 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kirk Lund, and Mark Bretl.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2142: Add JSON usage to NOTICE 
> 
> GEODE-2142: Remove JSON dependency from pulse
> 
> Remove the Cat-X licensed JSON software from geode-pulse and replace
> it with the friendly open-json replacement.  See
> https://github.com/tdunning/open-json.
> 
> Update copyright date in NOTICE
> 
> 
> Diffs
> -
> 
>   NOTICE 4801b2aedf4f254c85cba9f27d2f99d2ca2e046b 
>   geode-assembly/src/main/dist/NOTICE 
> 83d0f3313a01881c9c651077036c17f962cd38b9 
>   geode-pulse/build.gradle 94f26f7a4106ea085ba1bc9a7001967f6b47a863 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CDL.java 
> 6243f8f599342dbdf00d3b541dfeca9da5def508 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/Cookie.java
>  1a0fa6fb7c1edd8b81bd4513ea6786a8ba4ba59c 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CookieList.java
>  99498f500fec9d85a30b610564c706731a55ed68 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTP.java
>  234d2bddc483f71503f84886be949f2b93a7ddd6 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTPTokener.java
>  09b68d872f492f65cff14a02997dbae657027992 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONArray.java
>  0db27363e51eaa4e7d40724ea82ed29975df46c4 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONException.java
>  fbd8866cd59817b588b84ae3bceb6e39f49fa8e2 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONML.java
>  fc19ca549da14441c8895bce56d46bf880b13c90 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONObject.java
>  13f2ccad8c24a346ef8eb20cd195f5bf53211eeb 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONString.java
>  45585c75dbe5c0dd50359117713e078263dfb7b3 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONStringer.java
>  8c5ff0826d5f6ad998d39ee73ef4a255e5fc0423 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONTokener.java
>  0f4b7ee8f017c1f561f954dab1e409236d382bf2 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONWriter.java
>  dea900ab240b9a1b25079dec43c1e775e7caef76 
>   geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/README 
> 2d7cdcf8a0ccdd29e0b1a3337da4338a51649bce 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XML.java 
> 25675f89b6d2e22fced09dd366b18753f28b3ab7 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XMLTokener.java
>  ff81731e11b49b649b92580fd169440c734a1006 
>   geode-pulse/src/main/webapp/META-INF/NOTICE 
> 706eda265cf0b54c73d01df85c0a79bde9082d8a 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/BaseServiceTest.java
>  ccc147d1533142d54c8c7378c935da8f5e3234f5 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionServiceTest.java
>  77e6dd89340c59f7c15363a1d878ca3b6165d90a 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionsMemberServiceTest.java
>  512cfc78e811a3234f170b243cf3983a96fc4788 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/MemberGatewayHubServiceTest.java
>  980a772a6a43a60befe3f4cec2c898b3e62ad038 
>   geode-web-api/src/main/webapp/META-INF/NOTICE 
> 21082b6de4fbd7ba4ec4bcb61e9e1bfda5ac162a 
>   geode-web/src/main/webapp/META-INF/NOTICE 
> 8c6e1d7faf3188599305f44c44318f6e6cfd00e6 
>   gradle/dependency-versions.properties 
> 828b0882d0813919e699d1ec83c7ba9c59f0220e 
> 
> Diff: https://reviews.apache.org/r/55280/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: [jira] [Updated] (GEODE-1960) Provide protection against malicious developer jars deployed as functions

[Michael Stolz]

This is the beginning of a long and slippery slope to the end of the road.
There is no way to actually achieve what the title says.
You cannot identify in advance every threat that is going to come in the
future.
If you can't trust the people who are authorized to deploy code then your
business is over.
Just my humble opinion.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Fri, Jan 6, 2017 at 6:40 PM, Kirk Lund (JIRA)  wrote:

>
>  [ https://issues.apache.org/jira/browse/GEODE-1960?page=
> com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Kirk Lund updated GEODE-1960:
> -
> Labels: ClassLoader DeployCommand deploy  (was: DeployCommand deploy)
>
> > Provide protection against malicious developer jars deployed as functions
> > 
> -
> >
> > Key: GEODE-1960
> > URL: https://issues.apache.org/jira/browse/GEODE-1960
> > Project: Geode
> >  Issue Type: Improvement
> >  Components: functions, security
> >Reporter: Diane Hardman
> >Priority: Minor
> >  Labels: ClassLoader, DeployCommand, deploy
> >
> > Provide protection for functions that might contain malicious calls like
> System.exit().
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

[jira] [Commented] (GEODE-1960) Provide protection against malicious developer jars deployed as functions

[Roman Shaposhnik (JIRA)]

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

Roman Shaposhnik commented on GEODE-1960:
-

[~dhardman] just so I understand, are you talking about a concept similar to 
what, lets say Apache Tomcan is doing with its security manager? E.g. 
http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html

> Provide protection against malicious developer jars deployed as functions
> -
>
> Key: GEODE-1960
> URL: https://issues.apache.org/jira/browse/GEODE-1960
> Project: Geode
>  Issue Type: Improvement
>  Components: functions, security
>Reporter: Diane Hardman
>Priority: Minor
>  Labels: ClassLoader, DeployCommand, deploy
>
> Provide protection for functions that might contain malicious calls like 
> System.exit().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: copy files to servers

[Roman Shaposhnik]

Btw, I'm sure a comparison of capabilities with Ignite will come up at
some point. So here's what
they do in this department (which I personally find really cool):
   http://apacheignite.gridgain.org/v1.0/docs/zero-deployment

Thanks,
Roman.

On Fri, Jan 6, 2017 at 12:11 PM, Anthony Baker  wrote:
> Hmmm, I agree with Udo.  I’d like to push a new version of my application 
> with a single idempotent command.  The server should be smart enough to 
> figure out what's in my bundle and understand how to deploy it including any 
> dependencies (because who writes dependency-free code?).
>
> I do want some lifecycle hooks to alloc/free resources.  This seems 
> conceptually similar to the “war” model which is pretty familiar to most Java 
> devs.
>
> Anthony
>
>> On Jan 6, 2017, at 11:37 AM, Udo Kohlmeyer  wrote:
>>
>> In some ways that is a great idea but sometimes too explicit... Do we 
>> expect them to have fine grained jars?
>> Also how do we handle dependencies as a single util class might be used 
>> by both a cache-listener and a partition listener... is the expectation that 
>> we update the dependent util class for one but not the other
>>
>> It's a very grey area
>>
>> On 1/6/17 11:19, John Blum wrote:
>>> How about...
>>>
>>> * deploy function
>>> * deploy cache-listener
>>> * deploy cache-loader
>>> * deploy cache-loader
>>> * deploy resource (jar, xml, properties, etc)
>>> * etc.
>>>
>>> Might as was make it explicit.  For instance, I may have a JAR file I just
>>> deployed (uploaded) that contains Functions, Listeners, Loaders, Writers,
>>> etc but I only want to deploy functions.
>>>
>>> Having 1 uber "deploy" command with many options gets cumbersome.
>>>
>>> It is a simple matter to introduce multiple command but have those commands
>>> share similar logic.  This would also enable different workflows for
>>> different commands in a more non-convoluted, maintainable way.
>>>
>>> These could be matched with corresponding `undeploy` commands.
>>>
>>> Food for thought,
>>>
>>> John
>>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:
>>>
 With appropriate constraints, a copy file type command could be secure.

 1) don't use Apache Geode without security AND make the command require
 authorization permissions
 2) limit the target directory to a directory under the working directory of
 the remote server
 3) rename it to "deploy resource" so people don't expect it to copy to an
 arbitrary target directory on the remote machine

 Back to "deploy jar":

 The deploy command is only for deploying Apache Geode callbacks (Function,
 CacheListener, etc). "deploy resource" such Spring jars or Spring xml files
 or anything similar does not overlap with "deploy jar". There is continued
 confusion over what "deploy jar" is or does. I propose we rename it to
 "deploy functions" or "deploy callbacks" or something along those lines to
 end the confusion.

 On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz  wrote:

> So maybe a generic copy command is too insecure, I agree.
> What we should do is think about exactly what files we think we are
 trying
> to deploy.
>
>1. I believe that there is a need to deploy dependency jars into the
>system classpath.
>2. I believe that there is also a desire to be able to deploy Spring
>Data Geode xml configuration files.
>3. There is also an issue with attempting to deploy Spring Data Geode
>functions that we should try to work out.
>
> Anything else that anyone is aware of?
>
>
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: 631-835-4771
>
> On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett 
> wrote:
>
>> Agree with Anthony. A copy command would either duplicate what deploy
> does
>> by only putting files within as specific location in the server's
> directory
>> or creating a security nightmare if allowed to write anywhere on the
> host.
>>
>> On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker 
 wrote:
>>> I think there are lots of great OS orchestration and automation
 tools.
>>> I’m not sure I understand the need for `gfsh cp`.  If I could easily
> grab
>>> the member hostnames from `gfsh list members` and pipe them into
 mpssh
>> (for
>>> example) that would do the job.
>>>
>>> I *do* like the idea of an improved `gfsh deploy` that supports hot
>> deploy
>>> and reconfiguration.
>>>
>>> Anthony
>>>
 On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar >> wrote:
 Some application may need to copy files to all the servers. These
> files
 could either be data files or they could be configuration files
> needed
>> by
 the application or they could be jar files (that don't have
 functions
>>

Re: copy files to servers

[Kirk Lund]

That's very cool! I look forward to seeing how they dynamically pull in
remote transitive dependencies over the wire such as Spring, JDBC drivers
and other libraries that deployed classes reference and use. That sounds
tricky!

Re: copy files to servers

[Kirk Lund]

Oh, nevermind... I just read the section under "3rd Party Libraries." It's
still cool though.


On Fri, Jan 6, 2017 at 6:15 PM, Kirk Lund  wrote:

> That's very cool! I look forward to seeing how they dynamically pull in
> remote transitive dependencies over the wire such as Spring, JDBC drivers
> and other libraries that deployed classes reference and use. That sounds
> tricky!
>
>

Re: Review Request 55280: GEODE-2142: Remove JSON from pulse

[Anthony Baker]

> On Jan. 7, 2017, 12:27 a.m., Mark Bretl wrote:
> > Will there be another changeset to remove the code from geode-json 
> > sub-project as well?

Yes, we will need one.  That's a more complicated change because we can't use a 
drop-in replacement (see GEODE-629).


- Anthony


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


On Jan. 6, 2017, 9:09 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55280/
> ---
> 
> (Updated Jan. 6, 2017, 9:09 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kirk Lund, and Mark Bretl.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2142: Add JSON usage to NOTICE 
> 
> GEODE-2142: Remove JSON dependency from pulse
> 
> Remove the Cat-X licensed JSON software from geode-pulse and replace
> it with the friendly open-json replacement.  See
> https://github.com/tdunning/open-json.
> 
> Update copyright date in NOTICE
> 
> 
> Diffs
> -
> 
>   NOTICE 4801b2aedf4f254c85cba9f27d2f99d2ca2e046b 
>   geode-assembly/src/main/dist/NOTICE 
> 83d0f3313a01881c9c651077036c17f962cd38b9 
>   geode-pulse/build.gradle 94f26f7a4106ea085ba1bc9a7001967f6b47a863 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CDL.java 
> 6243f8f599342dbdf00d3b541dfeca9da5def508 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/Cookie.java
>  1a0fa6fb7c1edd8b81bd4513ea6786a8ba4ba59c 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/CookieList.java
>  99498f500fec9d85a30b610564c706731a55ed68 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTP.java
>  234d2bddc483f71503f84886be949f2b93a7ddd6 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/HTTPTokener.java
>  09b68d872f492f65cff14a02997dbae657027992 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONArray.java
>  0db27363e51eaa4e7d40724ea82ed29975df46c4 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONException.java
>  fbd8866cd59817b588b84ae3bceb6e39f49fa8e2 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONML.java
>  fc19ca549da14441c8895bce56d46bf880b13c90 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONObject.java
>  13f2ccad8c24a346ef8eb20cd195f5bf53211eeb 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONString.java
>  45585c75dbe5c0dd50359117713e078263dfb7b3 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONStringer.java
>  8c5ff0826d5f6ad998d39ee73ef4a255e5fc0423 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONTokener.java
>  0f4b7ee8f017c1f561f954dab1e409236d382bf2 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/JSONWriter.java
>  dea900ab240b9a1b25079dec43c1e775e7caef76 
>   geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/README 
> 2d7cdcf8a0ccdd29e0b1a3337da4338a51649bce 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XML.java 
> 25675f89b6d2e22fced09dd366b18753f28b3ab7 
>   
> geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/json/XMLTokener.java
>  ff81731e11b49b649b92580fd169440c734a1006 
>   geode-pulse/src/main/webapp/META-INF/NOTICE 
> 706eda265cf0b54c73d01df85c0a79bde9082d8a 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/BaseServiceTest.java
>  ccc147d1533142d54c8c7378c935da8f5e3234f5 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionServiceTest.java
>  77e6dd89340c59f7c15363a1d878ca3b6165d90a 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/ClusterSelectedRegionsMemberServiceTest.java
>  512cfc78e811a3234f170b243cf3983a96fc4788 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/junit/MemberGatewayHubServiceTest.java
>  980a772a6a43a60befe3f4cec2c898b3e62ad038 
>   geode-web-api/src/main/webapp/META-INF/NOTICE 
> 21082b6de4fbd7ba4ec4bcb61e9e1bfda5ac162a 
>   geode-web/src/main/webapp/META-INF/NOTICE 
> 8c6e1d7faf3188599305f44c44318f6e6cfd00e6 
>   gradle/dependency-versions.properties 
> 828b0882d0813919e699d1ec83c7ba9c59f0220e 
> 
> Diff: https://reviews.apache.org/r/55280/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

[jira] [Commented] (GEODE-2142) Remove JSON.org dependency

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2142:


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

GEODE-2142: Add JSON usage to NOTICE


> Remove JSON.org dependency
> --
>
> Key: GEODE-2142
> URL: https://issues.apache.org/jira/browse/GEODE-2142
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Anthony Baker
>Priority: Blocker
>
> ASF has determined that the JSON library should be treated as Category X and 
> is incompatible with ASLv2.
> We have until Apr-30, 2017 to remove this dependency.  Any release we ship 
> prior to that time must state this usage via NOTICE.
> http://mail-archives.apache.org/mod_mbox/incubator-general/201611.mbox/%3ccajwfca2ox62mugp+-+-v6ktbkhhgkixucjcr9syes-azfp+...@mail.gmail.com%3e
> There are related reasons for removing the JSON library anyway, but this bug 
> captures the legal reasons.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2142) Remove JSON.org dependency

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2142:


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

GEODE-2142: Remove JSON dependency from pulse

Remove the Cat-X licensed JSON software from geode-pulse and replace
it with the friendly open-json replacement.  See
https://github.com/tdunning/open-json.


> Remove JSON.org dependency
> --
>
> Key: GEODE-2142
> URL: https://issues.apache.org/jira/browse/GEODE-2142
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Anthony Baker
>Priority: Blocker
>
> ASF has determined that the JSON library should be treated as Category X and 
> is incompatible with ASLv2.
> We have until Apr-30, 2017 to remove this dependency.  Any release we ship 
> prior to that time must state this usage via NOTICE.
> http://mail-archives.apache.org/mod_mbox/incubator-general/201611.mbox/%3ccajwfca2ox62mugp+-+-v6ktbkhhgkixucjcr9syes-azfp+...@mail.gmail.com%3e
> There are related reasons for removing the JSON library anyway, but this bug 
> captures the legal reasons.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2142) Remove JSON.org dependency

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-2142:
--

When this is complete, we can remove the JSON blurbs from LICENSE and NOTICE.

> Remove JSON.org dependency
> --
>
> Key: GEODE-2142
> URL: https://issues.apache.org/jira/browse/GEODE-2142
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Anthony Baker
>Priority: Blocker
>
> ASF has determined that the JSON library should be treated as Category X and 
> is incompatible with ASLv2.
> We have until Apr-30, 2017 to remove this dependency.  Any release we ship 
> prior to that time must state this usage via NOTICE.
> http://mail-archives.apache.org/mod_mbox/incubator-general/201611.mbox/%3ccajwfca2ox62mugp+-+-v6ktbkhhgkixucjcr9syes-azfp+...@mail.gmail.com%3e
> There are related reasons for removing the JSON library anyway, but this bug 
> captures the legal reasons.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-1577) Unhelpful generic types on Execution.execute

[Alyssa Kim (JIRA)]

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

Alyssa Kim updated GEODE-1577:
--
Assignee: Dan Smith  (was: Alyssa Kim)

> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>Assignee: Dan Smith
>  Labels: starter
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (GEODE-1577) Unhelpful generic types on Execution.execute

[Alyssa Kim (JIRA)]

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

Alyssa Kim edited comment on GEODE-1577 at 1/7/17 3:44 AM:
---

[~upthewaterspout] Please assign it back to me when we decide what needs to be 
done here. I will hold off this one and another jira(GEODE-728) that requires a 
API change until then.
Thank you!


was (Author: dalyssakim):
[~upthewaterspout] Let me know when we decide what needs to be done here. I 
will hold off this one and another jira(GEODE-728) that requires a API change 
until then.
Thank you!

> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>Assignee: Dan Smith
>  Labels: starter
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)