GEODE-4168 Can't get json object stored as PDX using the new protocol #1209
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GEODE-4116 Can't get PDX objects using the new protocol Added a distributed test to ensure end-to-end handling of JSON documents is functioning correctly. For GEODE-4168 I changed the class-check from equals() to isAssignableFrom(). For GEODE-4116 I modified the Get and GetAll operation handlers to inhibit deserialization of PdxInstances when reading values from the cache. The test for 4116 ensures that the value is in serialized form by putting it into a distributed Region in another JVM. There are unrelated javadoc changes in this commit for DM.java and a couple of classes in the protobuf Driver module. I also added constraints to the Regions in the Driver's unit test to get rid of compilation warnings.
PivotalSarge
approved these changes
Jan 2, 2018
| @@ -455,7 +455,10 @@ void addHostedLocators(InternalDistributedMember member, Collection<String> loca | |||
| /** | |||
| * returns the type of node | |||
| * | |||
| * @return | |||
| * @see DistributionManager#NORMAL_DM_TYPE | |||
There was a problem hiding this comment.
Great addition to the Java docs.
|
|
||
| Assert.assertTrue(result instanceof Success); | ||
| PdxInstance pdxInstance = (PdxInstance) getCache().getRegion(regionName).get(key); | ||
| assertEquals("__GEMFIRE_JSON", pdxInstance.getClassName()); |
There was a problem hiding this comment.
Is there a constant that could be used instead of the string literal?
There was a problem hiding this comment.
I looked for a constant but couldn't find one
upthewaterspout
approved these changes
Jan 2, 2018
| // test hook | ||
| @Override | ||
| public void setReadSerialized(boolean value) { | ||
| public void setReadSerializedForTest(boolean value) { |
There was a problem hiding this comment.
Can we deprecate setReadSerializedForTest and tell people not to use it? I can't really see a valid use case for changing this value on the fly. I do see some existing yucky tests that are trying to test 20 things without closing the cache that seem to be using this method.
There was a problem hiding this comment.
I'll add a deprecation annotation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
& GEODE-4116 Can't get PDX objects using the new protocol
Added a distributed test to ensure end-to-end handling of JSON documents
is functioning correctly. For GEODE-4168 I changed the class-check from
equals() to isAssignableFrom(). For GEODE-4116 I modified the Get and
GetAll operation handlers to inhibit deserialization of PdxInstances
when reading values from the cache. The test for 4116 ensures that
the value is in serialized form by putting it into a distributed Region
in another JVM.
There are unrelated javadoc changes in this commit for DM.java and
a couple of classes in the protobuf Driver module. I also added
constraints to the Regions in the Driver's unit test to get rid of
compilation warnings.
@galen-pivotal @PivotalSarge @WireBaron @upthewaterspout
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Has your PR been rebased against the latest commit within the target branch (typically
develop)?Is your initial contribution a single, squashed commit?
Does
gradlew buildrun cleanly?Have you written or updated unit tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.