[GitHub] incubator-geode pull request #243: Marked test guaranteed to take at least 1...

2016-09-20 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/243


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

Re: Review Request 52052: GEODE-1128: Enhance missing-disk-stores command with missing regions

2016-09-20 Thread Darrel Schneider 

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


Ship it!




Ship It!

- Darrel Schneider


On Sept. 19, 2016, 12:12 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52052/
> ---
> 
> (Updated Sept. 19, 2016, 12:12 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, 
> Scott Jewell, Swapnil Bawaskar, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Refactored “show missing-disk-stores command” and added a section to the
> output to show missing colocated regions. Corrected messages in
> LocalizedStrings, change “gemfire list-missing-disk-stores” to
> “gfsh show missing-disk-stores”. Added new command function class to gather
> both missing disk-store and missing colocated region information on a
> distributed system member.
> 
> Parameterized show missing-disk-store error message.
> 
> Added new DataSerializable class for sending missing colocated region
> results to gfsh command.
> 
> Refactored ColocationLogger. Class originally deferred updating the list
> of missing colocated children (i.e. removing regions from the missing
> list that are now present) for a region until the next logging
> interval. This has been changed to update the list on-demand, whenever
> getMissingChildRegions() is called.
> 
> Added DUnit test for new functionality in show missing-disk-store
> command.
> 
> Added JUnit tests for new classes
> 
> New command oputput formats:
> 
> When there are no problems to report --
> 
> No missing disk store found
> No missing colocated region found
> 
> 
> Missing disk-stores (no missing colocated regions)
> 
> Missing Disk Stores
>Disk Store ID |  Host  | Directory
>  | -- | 
> -
> 8c204b3a-47ca-4bf4-ab3d-e6f704ea6ac6 | /10.118.33.251 | 
> /vm1/DiskStoreCommandsDUnitTest1
> 
> No missing colocated region found
> 
> 
> Missing colocated regions (no missing disk-stores) --
> 
> No missing disk store found
> 
> Missing Colocated Regions
> Host  | Distributed Member |   Parent Region  
>  | Missing Colocated Region
> - | -- | 
> - | 
> 10.118.33.251 | Manager| 
> /testShowPersistentRecoveryFailuresRegion | /childRegion
> 10.118.33.251 | VM1| 
> /testShowPersistentRecoveryFailuresRegion | /childRegion
> 
> 
> Missing disk-stores and missing colocated regions -
> 
> Missing Disk Stores
>Disk Store ID |  Host  | Directory
>  | -- | 
> -
> 09055140-cc35-48e1-a53a-91c0f5eb6644 | /10.118.33.251 | 
> /vm1/DiskStoreCommandsDUnitTest1
> 
> Missing Colocated Regions
> Host  | Distributed Member |   Parent Region  
>  | Missing Colocated Region
> - | -- | 
> - | 
> 10.118.33.251 | VM1| 
> /testShowPersistentRecoveryFailuresRegion | /childRegion
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ColocationLogger.java
>  0a3754763062c8f72b776085533bc1aeae87064b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/ColocatedRegionDetails.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java 
> b61201ef60b4dc3ea6d42e7ae30d305e2ebb7e35 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  53f910854ab3e929821d19a27b74f5e6fb6d7ecc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunction.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  1f0420b5eab16208135da47d862dfec3048f5548 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/ColocatedRegionDetailsJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommandsDUnitTest.java
>  9926ae67aedb4a520d4875e180b3408b35387bcd 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedDataSerializables.txt
>  2240daf7ccc5b2283633687220776e5894c7235c 
>   
> geode-core/src/test/resources/org/apache/g

Re: Review Request 52052: GEODE-1128: Enhance missing-disk-stores command with missing regions

2016-09-20 Thread Darrel Schneider 

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




geode-core/src/main/java/org/apache/geode/internal/cache/ColocationLogger.java 
(line 149)


should this be renamed to "updateAndGet..."?


- Darrel Schneider


On Sept. 19, 2016, 12:12 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52052/
> ---
> 
> (Updated Sept. 19, 2016, 12:12 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, 
> Scott Jewell, Swapnil Bawaskar, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Refactored “show missing-disk-stores command” and added a section to the
> output to show missing colocated regions. Corrected messages in
> LocalizedStrings, change “gemfire list-missing-disk-stores” to
> “gfsh show missing-disk-stores”. Added new command function class to gather
> both missing disk-store and missing colocated region information on a
> distributed system member.
> 
> Parameterized show missing-disk-store error message.
> 
> Added new DataSerializable class for sending missing colocated region
> results to gfsh command.
> 
> Refactored ColocationLogger. Class originally deferred updating the list
> of missing colocated children (i.e. removing regions from the missing
> list that are now present) for a region until the next logging
> interval. This has been changed to update the list on-demand, whenever
> getMissingChildRegions() is called.
> 
> Added DUnit test for new functionality in show missing-disk-store
> command.
> 
> Added JUnit tests for new classes
> 
> New command oputput formats:
> 
> When there are no problems to report --
> 
> No missing disk store found
> No missing colocated region found
> 
> 
> Missing disk-stores (no missing colocated regions)
> 
> Missing Disk Stores
>Disk Store ID |  Host  | Directory
>  | -- | 
> -
> 8c204b3a-47ca-4bf4-ab3d-e6f704ea6ac6 | /10.118.33.251 | 
> /vm1/DiskStoreCommandsDUnitTest1
> 
> No missing colocated region found
> 
> 
> Missing colocated regions (no missing disk-stores) --
> 
> No missing disk store found
> 
> Missing Colocated Regions
> Host  | Distributed Member |   Parent Region  
>  | Missing Colocated Region
> - | -- | 
> - | 
> 10.118.33.251 | Manager| 
> /testShowPersistentRecoveryFailuresRegion | /childRegion
> 10.118.33.251 | VM1| 
> /testShowPersistentRecoveryFailuresRegion | /childRegion
> 
> 
> Missing disk-stores and missing colocated regions -
> 
> Missing Disk Stores
>Disk Store ID |  Host  | Directory
>  | -- | 
> -
> 09055140-cc35-48e1-a53a-91c0f5eb6644 | /10.118.33.251 | 
> /vm1/DiskStoreCommandsDUnitTest1
> 
> Missing Colocated Regions
> Host  | Distributed Member |   Parent Region  
>  | Missing Colocated Region
> - | -- | 
> - | 
> 10.118.33.251 | VM1| 
> /testShowPersistentRecoveryFailuresRegion | /childRegion
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ColocationLogger.java
>  0a3754763062c8f72b776085533bc1aeae87064b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/ColocatedRegionDetails.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java 
> b61201ef60b4dc3ea6d42e7ae30d305e2ebb7e35 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  53f910854ab3e929821d19a27b74f5e6fb6d7ecc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunction.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  1f0420b5eab16208135da47d862dfec3048f5548 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/ColocatedRegionDetailsJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommandsDUnitTest.java
>  9926ae67aedb4a520d4875e180b3408b35387bcd 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/s

[GitHub] incubator-geode pull request #243: Marked test guaranteed to take at least 1...

2016-09-20 Thread jaredjstewart 
GitHub user jaredjstewart opened a pull request:

https://github.com/apache/incubator-geode/pull/243

Marked test guaranteed to take at least 1 minute as an integration test

This test is guaranteed to take at least 65 seconds to run.  Our 
[wiki](https://cwiki.apache.org/confluence/display/GEODE/Writing+tests) says 
that UnitTests should run in milliseconds.  I have marked it as an 
IntegrationTest to speed up our builds.

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

$ git pull https://github.com/jaredjstewart/incubator-geode 
markSlowTestAsIntegrationTest

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

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


commit 6de5700aac5b9380fccb7a4ee39f5f032623095e
Author: Jared Stewart 
Date:   2016-09-20T23:10:39Z

Marked test guarenteed to take at least 1 minute as an integration test




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

Re: Review Request 52076: GEODE-1511: Remove test dependencies from pom file

2016-09-20 Thread Anthony Baker 


> On Sept. 20, 2016, 5:33 p.m., Dan Smith wrote:
> > I don't think having this special logic for slf4j-impl is necessary because 
> > slf4j-impl already marked optional. It was *not* optional in M3, because of 
> > GEODE-1811. So I think this bug was already fixed by GEODE-1811.
> > 
> > As far as including/excluding test dependencies, I don't think it really 
> > matters since they have no effect. But maybe we should just stick with the 
> > default behavior of the gradle plugin?

Ok, makes sense.  I'll drop this change.


- Anthony


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


On Sept. 20, 2016, 3:49 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52076/
> ---
> 
> (Updated Sept. 20, 2016, 3:49 a.m.)
> 
> 
> Review request for geode, Dick Cavender, Jens Deppe, Mark Bretl, and Dan 
> Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove test dependecies from pom as they are not needed for geode
> applications. Also removes the log4j-slf4j-impl logging bridge.
> This reduces the possibility for conflicts on the application
> classpath.  The bridge jar is still present on the server
> classpath.
> 
> 
> Diffs
> -
> 
>   gradle/publish.gradle 8a579c2f166d42d980fec9bf01a2ecb2364ddacf 
> 
> Diff: https://reviews.apache.org/r/52076/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 52101: GEODE-1791: Update LICENSE

2016-09-20 Thread Joey McAllister 

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




LICENSE (line 330)


v1.8.0



LICENSE (line 364)


Add comma to "(http://sizzlejs.com/), Copyright"



geode-assembly/src/main/dist/LICENSE (line 676)


v1.8.0



geode-assembly/src/main/dist/LICENSE (line 711)


Add comma to "(http://sizzlejs.com/), Copyright"


Fix, then ship 👍

- Joey McAllister


On Sept. 20, 2016, 10:44 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52101/
> ---
> 
> (Updated Sept. 20, 2016, 10:44 p.m.)
> 
> 
> Review request for geode, Jens Deppe and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Edit LICENSE files to add jQuery version, MooTools, and sizzle.js.
> 
> GEODE-1791: update mbean src headers
> 
> Add src header for mbeans-descriptors.dtd and mbeans-descriptors.xml.
> The dtd is from an ASF project and the xml file is specific for
> geode--both of these require the standard ASF source header.
> 
> 
> Diffs
> -
> 
>   LICENSE 8109496d46f62cadfcf9159bf1f82a3b4cc3d3be 
>   geode-assembly/src/main/dist/LICENSE 
> 375521ee29599898bc3a3434adffa6e8d2ea651f 
>   
> geode-core/src/main/resources/org/apache/geode/admin/jmx/internal/doc-files/mbeans-descriptors.dtd
>  2a8b7b4fae8890769eea22156c234d899f7b2809 
>   
> geode-core/src/main/resources/org/apache/geode/admin/jmx/mbeans-descriptors.xml
>  24086419319dd41f5daaf9db3f6c027b117e131d 
>   gradle/rat.gradle fc1ef40beb329681326c080430265ff9af5b2dc6 
> 
> Diff: https://reviews.apache.org/r/52101/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 52101: GEODE-1791: Update LICENSE

2016-09-20 Thread Jinmei Liao 

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


Ship it!




Ship It!

- Jinmei Liao


On Sept. 20, 2016, 10:44 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52101/
> ---
> 
> (Updated Sept. 20, 2016, 10:44 p.m.)
> 
> 
> Review request for geode, Jens Deppe and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Edit LICENSE files to add jQuery version, MooTools, and sizzle.js.
> 
> GEODE-1791: update mbean src headers
> 
> Add src header for mbeans-descriptors.dtd and mbeans-descriptors.xml.
> The dtd is from an ASF project and the xml file is specific for
> geode--both of these require the standard ASF source header.
> 
> 
> Diffs
> -
> 
>   LICENSE 8109496d46f62cadfcf9159bf1f82a3b4cc3d3be 
>   geode-assembly/src/main/dist/LICENSE 
> 375521ee29599898bc3a3434adffa6e8d2ea651f 
>   
> geode-core/src/main/resources/org/apache/geode/admin/jmx/internal/doc-files/mbeans-descriptors.dtd
>  2a8b7b4fae8890769eea22156c234d899f7b2809 
>   
> geode-core/src/main/resources/org/apache/geode/admin/jmx/mbeans-descriptors.xml
>  24086419319dd41f5daaf9db3f6c027b117e131d 
>   gradle/rat.gradle fc1ef40beb329681326c080430265ff9af5b2dc6 
> 
> Diff: https://reviews.apache.org/r/52101/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Review Request 52101: GEODE-1791: Update LICENSE

2016-09-20 Thread Anthony Baker 

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

Review request for geode, Jens Deppe and Joey McAllister.


Repository: geode


Description
---

Edit LICENSE files to add jQuery version, MooTools, and sizzle.js.

GEODE-1791: update mbean src headers

Add src header for mbeans-descriptors.dtd and mbeans-descriptors.xml.
The dtd is from an ASF project and the xml file is specific for
geode--both of these require the standard ASF source header.


Diffs
-

  LICENSE 8109496d46f62cadfcf9159bf1f82a3b4cc3d3be 
  geode-assembly/src/main/dist/LICENSE 375521ee29599898bc3a3434adffa6e8d2ea651f 
  
geode-core/src/main/resources/org/apache/geode/admin/jmx/internal/doc-files/mbeans-descriptors.dtd
 2a8b7b4fae8890769eea22156c234d899f7b2809 
  
geode-core/src/main/resources/org/apache/geode/admin/jmx/mbeans-descriptors.xml 
24086419319dd41f5daaf9db3f6c027b117e131d 
  gradle/rat.gradle fc1ef40beb329681326c080430265ff9af5b2dc6 

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


Testing
---


Thanks,

Anthony Baker

Speed up your Gradle tasks!

2016-09-20 Thread Jared Stewart 
I wanted to share a tip with everyone that may speed up your build and test 
execution times if you don’t already use it.  Before we can speed up these 
tasks, it would be helpful to measure their baseline.  This can be done by 
adding the --profile flag, e.g. executing “gradle test --profile”.  The 
--profile flag will generate an html report under ./build/reports/profile/ that 
gives you an explanation of exactly where Gradle is spending its time.  Here is 
my test report summary:

Description Duration
Total Build Time4m32.03s
Startup 0.600s
Settings and BuildSrc   0.037s
Loading Projects0.009s
Configuring Projects0.269s
Task Execution  4m30.90s

You can also click into the ‘Task Execution’ tab of the html page to get more 
fine grained details.

Now on to the tip.  Our Gradle build and test executions depend on building the 
source code for each of our submodules.  By default this is done sequentially, 
but we can tell Gradle to execute tasks from independent submodules in parallel 
by adding the --parallel flag. Let’s see if this speeds up our build time.  
Here is my test report summary from running “gradle test --profile --parallel”:

Description Duration
Total Build Time2m8.84s
Startup 0.608s
Settings and BuildSrc   0.054s
Loading Projects0.006s
Configuring Projects0.229s
Task Execution  5m0.68s

So the parallel flag cut our build time in half!  In case you want more details 
about parallel task execution in Gradle, see this section of the User Guide 
https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:parallel_execution
 
.

Re: Error loading cluster config serialized prior to repackage

2016-09-20 Thread Dan Smith 
I like your idea of having registered DataSwizzlers. Would registering a
DataSerializer for these classes work? It would be nice to just use the
extension mechanism that's already there.

-Dan

On Tue, Sep 20, 2016 at 1:29 PM, Bruce Schuchardt 
wrote:

> The repackage broke those two methods.  The oldPackage needs to replace
> "org.apache" with "com.gemstone".  It allows interaction with a locator
> from WAN sites and clients running GemFire.
>
> I'll fix that problem.
>
>
> Le 9/20/2016 à 11:53 AM, Kirk Lund a écrit :
>
>> If current develop attempts to read a cluster config that was persisted
>> prior to the repackage, our code now throws ClassNotFoundException. Turns
>> out Cluster Config is implemented by the
>> class org.apache.geode.management.internal.configuration.domain.Co
>> nfiguration
>> which is a DataSerializable. Unfortunately, a DataSerializableFixedID was
>> never added for this class, so the code resorts to using the fully
>> qualified class name.
>>
>> While brainstorming possible workarounds, we noticed a jgroups related
>> method in DataSerializer called swizzleClassNameForRead which is called
>> from readObject(DataInput):
>>
>>/**
>> * For backward compatibility we must swizzle the package of
>> * some classes that had to be moved when GemFire was open-
>> * sourced.  This preserves backward-compatibility.
>> *
>> * @param name the fully qualified class name
>> * @return the name of the class in this implementation
>> */
>>private static String swizzleClassNameForRead(String name) {
>>  String oldPackage = "org.apache.org.jgroups.stack.tcpserver";
>>  String newPackage = "org.apache.geode.distributed.
>> internal.tcpserver";
>>  String result = name;
>>  if (name.startsWith(oldPackage)) {
>>result = newPackage + name.substring(oldPackage.length());
>>  }
>>  return result;
>>}
>>
>> The package in red above never existed. I now have two questions: a) did
>> the repackage break this so that JGroups now need two swizzles (one for
>> the
>> jgroups upgrade and now a 2nd for the apache repackage)? b) can cluster
>> Configuration piggy back on this technique for handling the serialized
>> Configuration for cluster config?
>>
>> 1) jgroups upgrade
>>  String oldPackage = "com.gemstone.jgroups.stack.tcpserver";
>>  String newPackage = "org.apache.geode.distributed.
>> internal.tcpserver";
>>
>> 2) apache repackage for jgroups
>>  String oldPackage = "com.gemstone.gemfire.distribu
>> ted.internal.tcpserver
>> ";
>>  String newPackage = "org.apache.geode.distributed.
>> internal.tcpserver";
>>
>> 3) apache repackage for cluster config
>>  String oldPackage = "com.gemstone.gemfire.management.internal.
>> configuration.domain";
>>  String newPackage = "org.apache.geode.management.
>> internal.configuration.domain";
>>
>> Can anyone else think of something similar that might be broken? We could
>> scan the source code for DataSerializables that don't have a
>> corresponding DataSerializableFixedID.
>> Should we also scan for Serializable classes and try to determine if they
>> might be similarly persisted in a way that might break a feature?
>>
>> Is this the best way to handle this? Should we reorganize
>> swizzleClassNameForRead to be a series of registered DataSwizzlers?
>>
>> Thanks,
>> Kirk
>>
>>
>

Re: Error loading cluster config serialized prior to repackage

2016-09-20 Thread Bruce Schuchardt 
The repackage broke those two methods.  The oldPackage needs to replace 
"org.apache" with "com.gemstone".  It allows interaction with a locator 
from WAN sites and clients running GemFire.


I'll fix that problem.

Le 9/20/2016 à 11:53 AM, Kirk Lund a écrit :

If current develop attempts to read a cluster config that was persisted
prior to the repackage, our code now throws ClassNotFoundException. Turns
out Cluster Config is implemented by the
class org.apache.geode.management.internal.configuration.domain.Configuration
which is a DataSerializable. Unfortunately, a DataSerializableFixedID was
never added for this class, so the code resorts to using the fully
qualified class name.

While brainstorming possible workarounds, we noticed a jgroups related
method in DataSerializer called swizzleClassNameForRead which is called
from readObject(DataInput):

   /**
* For backward compatibility we must swizzle the package of
* some classes that had to be moved when GemFire was open-
* sourced.  This preserves backward-compatibility.
*
* @param name the fully qualified class name
* @return the name of the class in this implementation
*/
   private static String swizzleClassNameForRead(String name) {
 String oldPackage = "org.apache.org.jgroups.stack.tcpserver";
 String newPackage = "org.apache.geode.distributed.internal.tcpserver";
 String result = name;
 if (name.startsWith(oldPackage)) {
   result = newPackage + name.substring(oldPackage.length());
 }
 return result;
   }

The package in red above never existed. I now have two questions: a) did
the repackage break this so that JGroups now need two swizzles (one for the
jgroups upgrade and now a 2nd for the apache repackage)? b) can cluster
Configuration piggy back on this technique for handling the serialized
Configuration for cluster config?

1) jgroups upgrade
 String oldPackage = "com.gemstone.jgroups.stack.tcpserver";
 String newPackage = "org.apache.geode.distributed.internal.tcpserver";

2) apache repackage for jgroups
 String oldPackage = "com.gemstone.gemfire.distributed.internal.tcpserver
";
 String newPackage = "org.apache.geode.distributed.internal.tcpserver";

3) apache repackage for cluster config
 String oldPackage = "com.gemstone.gemfire.management.internal.
configuration.domain";
 String newPackage = "org.apache.geode.management.
internal.configuration.domain";

Can anyone else think of something similar that might be broken? We could
scan the source code for DataSerializables that don't have a
corresponding DataSerializableFixedID.
Should we also scan for Serializable classes and try to determine if they
might be similarly persisted in a way that might break a feature?

Is this the best way to handle this? Should we reorganize
swizzleClassNameForRead to be a series of registered DataSwizzlers?

Thanks,
Kirk

Error loading cluster config serialized prior to repackage

2016-09-20 Thread Kirk Lund 
If current develop attempts to read a cluster config that was persisted
prior to the repackage, our code now throws ClassNotFoundException. Turns
out Cluster Config is implemented by the
class org.apache.geode.management.internal.configuration.domain.Configuration
which is a DataSerializable. Unfortunately, a DataSerializableFixedID was
never added for this class, so the code resorts to using the fully
qualified class name.

While brainstorming possible workarounds, we noticed a jgroups related
method in DataSerializer called swizzleClassNameForRead which is called
from readObject(DataInput):

  /**
   * For backward compatibility we must swizzle the package of
   * some classes that had to be moved when GemFire was open-
   * sourced.  This preserves backward-compatibility.
   *
   * @param name the fully qualified class name
   * @return the name of the class in this implementation
   */
  private static String swizzleClassNameForRead(String name) {
String oldPackage = "org.apache.org.jgroups.stack.tcpserver";
String newPackage = "org.apache.geode.distributed.internal.tcpserver";
String result = name;
if (name.startsWith(oldPackage)) {
  result = newPackage + name.substring(oldPackage.length());
}
return result;
  }

The package in red above never existed. I now have two questions: a) did
the repackage break this so that JGroups now need two swizzles (one for the
jgroups upgrade and now a 2nd for the apache repackage)? b) can cluster
Configuration piggy back on this technique for handling the serialized
Configuration for cluster config?

1) jgroups upgrade
String oldPackage = "com.gemstone.jgroups.stack.tcpserver";
String newPackage = "org.apache.geode.distributed.internal.tcpserver";

2) apache repackage for jgroups
String oldPackage = "com.gemstone.gemfire.distributed.internal.tcpserver
";
String newPackage = "org.apache.geode.distributed.internal.tcpserver";

3) apache repackage for cluster config
String oldPackage = "com.gemstone.gemfire.management.internal.
configuration.domain";
String newPackage = "org.apache.geode.management.
internal.configuration.domain";

Can anyone else think of something similar that might be broken? We could
scan the source code for DataSerializables that don't have a
corresponding DataSerializableFixedID.
Should we also scan for Serializable classes and try to determine if they
might be similarly persisted in a way that might break a feature?

Is this the best way to handle this? Should we reorganize
swizzleClassNameForRead to be a series of registered DataSwizzlers?

Thanks,
Kirk

Re: jvsd

2016-09-20 Thread Dave Barnes 
To what degree should jVSD be mentioned in the docs? The current writeup is
essentially "go get it if you want it, but be warned that it's not fully
baked and we don't support it".
Would that still be the appropriate jVSD policy for 1.0.0?

On Tue, Sep 20, 2016 at 10:42 AM, Dan Smith  wrote:

> I don't think we should try to include jVSD in 1.0.0 at this point, because
> it introduces dependencies that might make the 1.0.0 release more
> complicated such as the MultiAxisChartFX dependency. But I think the should
> try to get it to develop sooner rather than later to make it easier for
> people to get jVSD and play with it.
>
> -Dan
>

Re: [VIRTUAL] Geode Clubhouse TOMORROW Weds, 9/21 10AM Pacific - Domain Driven Design & Reactive Programming w/ Apache Geode - Discussion Panel

2016-09-20 Thread Gregory Chase 
Dear Geode Community,
This is a reminder that tomorrow we have Vaughn Vernon and Wes Williams
joining us for a further discussion of Domain Driven Design and reactive
programming.

This is a follow on of the Webinar recently run by Pivotal: Why
Domain-Driven Design and Reactive Programming?

This
replay is now available and does not require registration.

Also, please note that this Geode Clubhouse has been moved to one hour
later than previously announced. (Now 10AM Pacific instead of 9AM Pacific).

This meeting will kickoff on Weds, Sept 21 at 10AM Pacific

<-
add to your calendar.

Note that we have a new meeting platform.  Here's how to join:

This meeting is being run with Zoom.  If its your first time using it, you
will be prompted to download their meeting client.

Video & audio streaming: Join from PC, Mac, Linux, iOS or Android:
https://pivotal.zoom.us/j/540483502

Optional phone audio connection:

Or iPhone one-tap (US Toll):  +14086380968,540483502# or +16465588656
,540483502#

Or Telephone:
Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
Meeting ID: 540 483 502
International numbers available: https://pivotal.zoom.us/
zoomconference?m=Jnvh-1uWfqE95Tb4M9AwS9X7P9oPTlfH


On Wed, Sep 14, 2016 at 10:44 AM, Gregory Chase  wrote:

> Dear Geode Community,
> I'm super excited to have Vaughn Vernon and Wes Williams joining the next
> Geode Clubhouse for a discussion about Domain Driven Design & Reactive
> programming in context with Apache Geode.
>
> This meeting will kickoff on Weds, Sept 21 at 10AM Pacific
> 
>  <-
> add to your calendar.
>
> This meeting is a follow on of the webinar running today at 11AM Pacific
> .
> I will reply with a replay link for this webinar when its available.
>
> Note that we have a new meeting platform.  Here's how to join:
>
> This meeting is being run with Zoom.  If its your first time using it, you
> will be prompted to download their meeting client.
>
> Video & audio streaming: Join from PC, Mac, Linux, iOS or Android:
> https://pivotal.zoom.us/j/540483502
>
> Optional phone audio connection:
>
> Or iPhone one-tap (US Toll):  +14086380968,540483502# or +16465588656
> ,540483502#
>
> Or Telephone:
> Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
> Meeting ID: 540 483 502
> International numbers available: https://pivotal.zoom.us/
> zoomconference?m=Jnvh-1uWfqE95Tb4M9AwS9X7P9oPTlfH
>
>
>
> --
> Greg Chase
>
> Global Head, Big Data Communities
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>
>


-- 
Greg Chase

Global Head, Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

Re: jvsd

2016-09-20 Thread Dan Smith 
I don't think we should try to include jVSD in 1.0.0 at this point, because
it introduces dependencies that might make the 1.0.0 release more
complicated such as the MultiAxisChartFX dependency. But I think the should
try to get it to develop sooner rather than later to make it easier for
people to get jVSD and play with it.

-Dan

Re: Review Request 52076: GEODE-1511: Remove test dependencies from pom file

2016-09-20 Thread Dan Smith 

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



I don't think having this special logic for slf4j-impl is necessary because 
slf4j-impl already marked optional. It was *not* optional in M3, because of 
GEODE-1811. So I think this bug was already fixed by GEODE-1811.

As far as including/excluding test dependencies, I don't think it really 
matters since they have no effect. But maybe we should just stick with the 
default behavior of the gradle plugin?

- Dan Smith


On Sept. 20, 2016, 3:49 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52076/
> ---
> 
> (Updated Sept. 20, 2016, 3:49 a.m.)
> 
> 
> Review request for geode, Dick Cavender, Jens Deppe, Mark Bretl, and Dan 
> Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove test dependecies from pom as they are not needed for geode
> applications. Also removes the log4j-slf4j-impl logging bridge.
> This reduces the possibility for conflicts on the application
> classpath.  The bridge jar is still present on the server
> classpath.
> 
> 
> Diffs
> -
> 
>   gradle/publish.gradle 8a579c2f166d42d980fec9bf01a2ecb2364ddacf 
> 
> Diff: https://reviews.apache.org/r/52076/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 52076: GEODE-1511: Remove test dependencies from pom file

2016-09-20 Thread Mark Bretl 

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


Ship it!




Ship It!

- Mark Bretl


On Sept. 19, 2016, 8:49 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52076/
> ---
> 
> (Updated Sept. 19, 2016, 8:49 p.m.)
> 
> 
> Review request for geode, Dick Cavender, Jens Deppe, Mark Bretl, and Dan 
> Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove test dependecies from pom as they are not needed for geode
> applications. Also removes the log4j-slf4j-impl logging bridge.
> This reduces the possibility for conflicts on the application
> classpath.  The bridge jar is still present on the server
> classpath.
> 
> 
> Diffs
> -
> 
>   gradle/publish.gradle 8a579c2f166d42d980fec9bf01a2ecb2364ddacf 
> 
> Diff: https://reviews.apache.org/r/52076/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: jvsd

2016-09-20 Thread Anthony Baker 
Hi Gal,

This page talks about the goals and status for jvsd:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61309918

Here’s another thread which discussed options for moving forward:
http://mail-archives.apache.org/mod_mbox/geode-dev/201605.mbox/%3c14840688a62caa4197a28aaccda9d2db11644...@ilraadagbe4.corp.amdocs.com%3E

The Geode community is currently discussing the scope for 1.0.0 [1] but so far 
jvsd is not in scope.

Anthony

[1] 
http://mail-archives.apache.org/mod_mbox/geode-dev/201609.mbox/%3ccak7stczfxw-q1ztjvymh2eqpvis5vhuuz834u5k7pdy1h0x...@mail.gmail.com%3e

> On Sep 20, 2016, at 5:35 AM, Gal Palmery  wrote:
> 
> Hi,
> 
> Is there a plan to merge jvsd to the develop branch in the near future ?
> 
> Thanks,
> Gal
> 
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: M3 is out - New release manager for 1.0 ?

2016-09-20 Thread Anthony Baker 
> 
> So, my proposal for issues to be targeted for 1.0 is:
> GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
> command's GetRegionsFunction
> GEODE-1466 Branding: rename gemfire.properties file to geode.properties file
> GEODE-17 Provide Integrated Security
> GEODE-37 (package renaming)
> GEODE-1791 (LICENSE update)
> 
> Thoughts?
> 

I found a few other minor issues that would be good to address in 1.0.0:

GEODE-1513 (duplicate jar files in wars)
GEODE-1511 (pom dependencies)

I’ve got review requests out for these changes.

Anthony



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: M3 is out - New release manager for 1.0 ?

2016-09-20 Thread Michael Stolz 
I think we should do these security features incrementally after 1.0.0.

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

On Mon, Sep 19, 2016 at 6:16 PM, Anthony Baker  wrote:

>
> > On Sep 17, 2016, at 5:29 PM, Swapnil Bawaskar 
> wrote:
> >
> > So, my proposal for issues to be targeted for 1.0 is:
> > GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
> > command's GetRegionsFunction
> > GEODE-1466 Branding: rename gemfire.properties file to geode.properties
> file
> > GEODE-17 Provide Integrated Security
> > GEODE-37 (package renaming)
> > GEODE-1791 (LICENSE update)
>
> GEODE-17 implies:
> GEODE-1569 (add post authorization processing in JMX and CLI
> commands)
> GEODE-1570 (secure developer REST API)
> GEODE-1571 (Client security should be able to use
> Resource:Operation permissions)
> GEODE-1648 (Provide ability to disable security for some
> components) **
> GEODE-1643 (The new SecurityManager need to authenticate the
> gateway sender/receiver as well)
> GEODE-1659 (Prevent misconfiguration of Integrated Security)
>
> Were you thinking all these security enhancements should be included in
> 1.0.0?  Seems like that could potentially be a lengthy process.  Does it
> make sense to release at these changes incrementally?
>
> The other items in scope for 1.0.0 look good to me.
>
> Anthony
>
>
> ** there was a recent discussion on this topic where the suggestion was to
> not allow per-component RBAC configuration: https://mail-archives.apache.
> org/mod_mbox/incubator-geode-dev/201609.mbox/%
> 3ccangouwssfmszbmlv9eq2kavgjtj_t2f1ad-qra8gzqmeq4t...@mail.gmail.com%3e
>
>
>

Build failed in Jenkins: Geode-nightly #598

2016-09-20 Thread Apache Jenkins Server 
See 

Changes:

[hkhamesra] GEODE-1908 DS.connect call not configuring p2p server with SSL.

[hkhamesra] GEODE-37 re-merge commit 6a109a7f57a5402af458d593d93c2e328bd3281b

[klund] GEODE-1905: Address UnknownPropertyException when running tests with

[ukohlmeyer] GEODE-1524: Updating swagger annotations to 1.3.13 Removing of 
escape

--
[...truncated 456 lines...]
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:distTar
:geode-assembly:distZip
:geode-assembly:writeBuildInfo
:geode-assembly:srcDistTar
:geode-assembly:srcDistZip
:geode-assembly:signArchives SKIPPED
:geode-assembly:assemble
:geode-assembly: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-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:checkMissedTests
:geode-assembly:installDist
:geode-assembly:test
:geode-assembly:check
:geode-assembly:build
:geode-assembly:distributedTest
:geode-assembly:flakyTest
:geode-assembly:integrationTest
:geode-common:assemble
:geode-common:compileTestJava
:geode-common:processTestResources UP-TO-DATE
:geode-common:testClasses
:geode-common:checkMissedTests
:geode-common:test
:geode-common:check
:geode-common:build
:geode-common:distributedTest
:geode-common:flakyTest
:geode-common:integrationTest
:geode-core:assemble
:geode-core:checkMissedTests
:geode-core:test
:geode-core:check
:geode-core:build
:geode-core:distributedTest
:geode-core:flakyTest

org.apache.geode.cache.management.MemoryThresholdsDUnitTest > testEventDelivery 
FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache.management.MemoryThresholdsDUnitTest$56.call in VM 0 
running on Host hemera.apache.org 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:320)
at 
org.apache.geode.cache.management.MemoryThresholdsDUnitTest.verifyListenerValue(MemoryThresholdsDUnitTest.java:1477)
at 
org.apache.geode.cache.management.MemoryThresholdsDUnitTest.testEventDelivery(MemoryThresholdsDUnitTest.java:509)

Caused by:
java.lang.AssertionError: Event never occurred after 3 ms: Remote 
CRITICAL assert failed TestListenerStatus: normalCalls :1 allCalls :3 
criticalThresholdCalls :1 evictionThresholdCalls :2 previousNormalCalls :1 
bytesFromThreshold :50 currentHeapPercentage :75 evictionDisabledCalls :0 
criticalDisabledCalls :0

185 tests completed, 1 failed, 6 skipped
:geode-core:flakyTest FAILED
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq: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-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:test
:geode-cq:check
:geode-cq:build
: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: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: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:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 
/x1/jenkins/jenkins-slave/workspace/Geode-nightly/geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/PulseAbstractTest.java
 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:

Re: Review Request 52019: GEODE-1513: Remove duplicate jars from war files

2016-09-20 Thread Anthony Baker 


> On Sept. 20, 2016, 2:17 p.m., Jens Deppe wrote:
> > geode-pulse.war contains geode-web.jar - I don't think it needs that.
> > 
> > Both geode-pulse.war and geode-web-api.war contain the relevant exploded 
> > classes. However, geode-web.war contains a geode-web.jar file with the 
> > actual classes. It would be nice to be consistent - whatever is easisest 
> > and clearer to set up in Gradle should be fine.

Unfortunately, geode-web.jar is generated in the geode-core project (for bad 
but necessary reasons that we should fix).  The simplest thing in gradle 
projects is to *not* bundle classes into a jar.


- Anthony


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


On Sept. 19, 2016, 1:11 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52019/
> ---
> 
> (Updated Sept. 19, 2016, 1:11 a.m.)
> 
> 
> Review request for geode, Dick Cavender, Jens Deppe, Jinmei Liao, and Mark 
> Bretl.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove duplicate jar files from the lib directory of the
> geode-web, geode-web-api, and geode-pulse war archives. Gradle
> doesn't appear to be doing the correct thing, so force it using
> a duplicates strategy.  In addition, do not create geode-web-api
> or geode-pulse jar files.  These don't seem to be used anywhere.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 3ed864ba5dd2e9589d5cb8313fe59747b76a91b0 
>   geode-pulse/build.gradle e53a698700f0de62088b3ac50cb96d4841315124 
>   geode-web-api/build.gradle 388dbba7c9c0bc9134dbd5818c49edb9d0eae7a6 
>   geode-web/build.gradle 75844d39678c5acc617e70f9cfa77c1049ca9d69 
> 
> Diff: https://reviews.apache.org/r/52019/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 52019: GEODE-1513: Remove duplicate jars from war files

2016-09-20 Thread Jens Deppe 

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



geode-pulse.war contains geode-web.jar - I don't think it needs that.

Both geode-pulse.war and geode-web-api.war contain the relevant exploded 
classes. However, geode-web.war contains a geode-web.jar file with the actual 
classes. It would be nice to be consistent - whatever is easisest and clearer 
to set up in Gradle should be fine.

- Jens Deppe


On Sept. 19, 2016, 1:11 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52019/
> ---
> 
> (Updated Sept. 19, 2016, 1:11 a.m.)
> 
> 
> Review request for geode, Dick Cavender, Jens Deppe, Jinmei Liao, and Mark 
> Bretl.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove duplicate jar files from the lib directory of the
> geode-web, geode-web-api, and geode-pulse war archives. Gradle
> doesn't appear to be doing the correct thing, so force it using
> a duplicates strategy.  In addition, do not create geode-web-api
> or geode-pulse jar files.  These don't seem to be used anywhere.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 3ed864ba5dd2e9589d5cb8313fe59747b76a91b0 
>   geode-pulse/build.gradle e53a698700f0de62088b3ac50cb96d4841315124 
>   geode-web-api/build.gradle 388dbba7c9c0bc9134dbd5818c49edb9d0eae7a6 
>   geode-web/build.gradle 75844d39678c5acc617e70f9cfa77c1049ca9d69 
> 
> Diff: https://reviews.apache.org/r/52019/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 52076: GEODE-1511: Remove test dependencies from pom file

2016-09-20 Thread Jens Deppe 

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


Ship it!




Ship It!

- Jens Deppe


On Sept. 20, 2016, 3:49 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52076/
> ---
> 
> (Updated Sept. 20, 2016, 3:49 a.m.)
> 
> 
> Review request for geode, Dick Cavender, Jens Deppe, Mark Bretl, and Dan 
> Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove test dependecies from pom as they are not needed for geode
> applications. Also removes the log4j-slf4j-impl logging bridge.
> This reduces the possibility for conflicts on the application
> classpath.  The bridge jar is still present on the server
> classpath.
> 
> 
> Diffs
> -
> 
>   gradle/publish.gradle 8a579c2f166d42d980fec9bf01a2ecb2364ddacf 
> 
> Diff: https://reviews.apache.org/r/52076/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

jvsd

2016-09-20 Thread Gal Palmery 
Hi,

Is there a plan to merge jvsd to the develop branch in the near future ?

Thanks,
Gal

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp