g sources
> > jar. If anyone knows what would cause this, let me know!
> >
> > On Tue, Jan 22, 2019 at 5:49 PM Galen O'Sullivan
> > wrote:
> >
> > > I'm getting the following failure building Geode on the latest develop.
> > > I've tr
I tried cleaning as well. It turns out that the directory I needed to
remove was `~/.m2`. I guess the package cache was corrupted. Transient
failure?
On Tue, Jan 22, 2019 at 5:49 PM Galen O'Sullivan
wrote:
> I'm getting the following failure building Geode on the latest develop.
I'm getting the following failure building Geode on the latest develop.
I've tried `rm -r .gradle ~/.gradle`, to no avail. Any ideas?
Thanks,
Galen
---
./gradlew dev
> Task :geode-core:compileIntegrationTestJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution faile
I'm for failing CI on warnings. It would be nice to reduce or eliminate our
existing build warnings as well.
Thanks,
Galen
On Tue, Jan 15, 2019 at 12:33 PM Peter Tran wrote:
> Hello!
>
> I've noticed that there is no mechanism in which we prevent new PRs from
> introduce new build warnings. In
The plan is to use tagged metrics, so for example, you could slice metrics
on puts by region, or server, or both.
On Tue, Jan 15, 2019 at 10:06 AM Udo Kohlmeyer wrote:
> I agree with Jacob here. Great to see such great strides forward
>
> +1 deprecating old Stats APIs
>
> It would be good to see
I suspect Udo is remembering something we both had to deal with, which is
that the lack of values to get/put PDXInstances on Regions make some
patterns difficult. In internal code, we have to set some thread-locals to
get serialized values out, and in general, I think that setting
pdx-read-serializ
Sounds good to me.
On Mon, Dec 17, 2018 at 1:04 PM Owen Nichols wrote:
> Sounds good, I would be happy to +1 a PR for this
>
> > On Dec 17, 2018, at 12:22 PM, Kirk Lund wrote:
> >
> > We have a custom annotation in geode-common called @TestingOnly:
> >
> > geode-common/src/main/java/org/apache/
I don't understand our build or IntelliJ that well, but it seems weird to
me that these classes would be getting built at all since they're in the
resources section rather than java. I don't see compiled versions of these
classes in my geode directory. Perhaps it's an IntelliJ configuration issue?
On the PR for https://github.com/apache/geode/pull/2938, the StressNewTest
and (in two different runs of the same code) other jobs fail occasionally.
I'm inclined to think that the Upgrade and Acceptance test failures were
caused by flaky tests, and I can keep rerunning the PR build.
The StressNe
>From the release notes:
> ConfigurationProperties.ssl-enabled-components supports `none` option as
advertised.
This is incorrect. The fix for GEODE-5830 was to remove "none" as an option.
Signatures and digests look good, gfsh works.
Speaking of verifying commits, does it make sense to sign rele
Can we just remove PowerMock from our dependencies and skip the rule? I'd
like to hope we can control our dependencies reasonably well.
On Tue, Dec 4, 2018 at 4:45 PM Ryan McMahon wrote:
> +1 to a spotless rule. Unless anyone objects, I’ll look into doing that
> after PowerMock is eliminated.
>
Jake,
This is awesome! I do have a question, though: would releasing such a
module info make it hard to improve upon later by giving the expectation of
one set of modules?
Thanks,
Galen
On Mon, Dec 3, 2018 at 4:44 PM Jacob Barrett wrote:
> Yeah that would fix one of a dozen “leaked” internal p
This would be a good addition to the AnalzeSerializablesJUnitTest. Banning
non-DSFID DataSerializables in product code seems like a good idea.
On Fri, Nov 30, 2018 at 2:12 PM Michael Stolz wrote:
> Jake thanks for bringing this up.
> Could have been a big waste of effort if you hadnt.
>
> --
> M
>
> If you want to
> maintain an API as internal, then you should properly protect that API with
> the appropriate *Java* access modifiers (private, package-private and
> protected).
>
Hopefully modules will allow us to do this better, by restricting which
*classes* are visible outside the module.
> > > rules are bad? Rules just encapsulate common befores and afters to
> avoid
> > > duplicate code in every tests. I don't see why we should avoid using
> it.
> > >
> > > On Fri, Nov 9, 2018, 3:44 PM Galen O'Sullivan > > wrote:
> > &
Hi all,
I wrote a PR (GEODE-5800) recently to remove redundant cases from
DataSerializer.readObject etc. calls. This changed the bytecode size (but
not the behavior) of a number of DataSerializables, and I realized that the
task of updating the list (or viewing the diff) was made harder by the fac
I'm in favor of this change, but only if we have a way to restart failing
PR builds without being the PR submitter. Any committer should be able to
restart the build. The pipeline is still flaky enough and I want to avoid
the situation where a new contributor is asked repeatedly to push empty
commi
against Testing APIs instead then
> > we
> > > > >> don't
> > > > >> feel the Users' pain if our API is painful. If the reason to use a
> > > Rule
> > > > is
> > > > >> because our User API is overly-verbo
I was looking at a test recently that extended JUnit4CacheTestCase and only
used a single server, and changed it to use ClusterStartupRule.
JUnit4CacheTestCase adds additional complexity to JUnit4DistributedTestCase
and with the move to ClusterStartupRule for distributed tests, rather than
class i
I'm pretty sure we want to keep the release tags for every release we've
made, in case someone wants to check something against old releases.
On Thu, Nov 8, 2018 at 5:04 PM Anthony Baker wrote:
> Notes:
>
> - Older release/* branches may be removed.
> - Do not remove branches like native-client-
I'm with Bill and John on this one. Give the top-level object only and let
users move down the object heirarchy.
On Thu, Nov 1, 2018 at 9:38 AM John Blum wrote:
> Well, ServerLauncher may or may not create a CacheServer instance when it
> starts a server. A server can be created without a Cache
I did a little more reading, and it sounds like we should create an
module-info.java to reserve the proper name for those customers who are
using Java 9+. See this article[1] for a description of what can go wrong
if people start using the automatic package without us having declared a
name. I thin
Thanks for keeping us updated and fixing this, Dan!
Galen
On Wed, Oct 17, 2018 at 3:48 PM Dan Smith wrote:
> Should be fixed now, if you rebase/merge on the latest develop.
>
> -Dan
>
>
> On Wed, Oct 17, 2018 at 3:10 PM Dan Smith wrote:
>
> > Hi all,
> >
> > It looks like some recent changes c
Would it be feasible to reserve chosen ports before selecting ephemeral
ports? I think this would resolve the collision issue described above.
On Thu, Oct 11, 2018 at 9:58 AM Brian Rowe wrote:
> I agree that we should have defaulted everything to using ephemeral ports
> and forced clients to exp
I think we should run some sort of backwards-compatibility tests between
Java 8 and Java 9/11+. We need testing of Geode (both old and current
versions) on older JVMs talking to Geode on newer JVMs. (for example, what
if Java built-in serialization changes in a way that breaks our code
somehow?)
O
er, lost the end of that first sentence there. I think that reducing
dependencies on Unsafe &c is a good goal regardless.
On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan
wrote:
> #1 sounds awesome but may be unrealistic given our advertised feature set.
> I think that reducing
#1 sounds awesome but may be unrealistic given our advertised feature set.
I think that reducing dependencies on Unsafe &c
If we can conditionally use Jigsaw modules for Java versions later than 8
while maintaining Java 8 compatiblity, that seems like the best solution.
+2 to Dan's idea if it all
This is excellent. Thanks for this improvement, Bruce.
On Fri, Oct 5, 2018 at 4:14 PM Jacob Barrett wrote:
> Maybe because you have too many Ps in your url. ;)
>
> > On Oct 5, 2018, at 3:56 PM, Bruce Schuchardt
> wrote:
> >
> > I think there's already one listing all of the deprecated APIs. Th
Hi,
I still haven't heard back about this. Can I have access? Who grants it? If
not, what are the criteria for inclusion?
Thanks,
Galen
On Thu, Sep 20, 2018 at 10:57 AM Galen O'Sullivan
wrote:
> Hi,
>
> I would like to have admin access to Concourse at
> https://concour
I was reviewing a PR recently and noticed that we have some test code that
uses Logger (or LogWriter). If I understand correctly, anything logged to
stdout will be included in the test output, and anything logged in a DUnit
VM will be logged with the appropriate VM number prepended in the output.
B
Hi,
I would like to have admin access to Concourse at
https://concourse.apachegeode-ci.info/ so that I can help maintain the
pipelines.
Thanks,
Galen
+1 to separate files. It's probably worth referencing the other files in
the README.
On Mon, Sep 17, 2018 at 12:16 PM, Jacob Barrett wrote:
> I prefer creating a TESTING.md to create a clear physical grouping around
> the subject. I like my read me files like my source, small and well
> organize
Hi all,
I remembered a couple email threads discussing how it was possible to debug
multiple DUnit processes from IntelliJ, but couldn't find a wiki article or
a very complete description, so I wrote a wiki article. It's a little
barebones right now, but there it is. Please edit or comment with an
;
> > >3. }
> > >
> > >
> > > Log4j2 lets you pass a format string, so you can just do this:
> > >
> > > logger.debug("Logging in user {} with birthday {}", user.getName(),
> > > user.getBirthdayCalendar());
> > >
>
Hi all,
I've noticed a pattern in Geode where we wrap a log call in a check at the
same level, such as:
if (logger.isDebugEnabled()) {
logger.debug("cleaning up incompletely started
DistributionManager due to exception", r);
}
Is there any reason to do this? To my mind, it'
+1
On Mon, Aug 27, 2018 at 10:06 AM, Kirk Lund wrote:
> Jira ticket as been filed for this:
>
> GEODE-5639: Replace usage of CatchException with AssertJ and remove
> CatchException dependency
>
> On Thu, Aug 23, 2018 at 4:03 PM, Kirk Lund wrote:
>
> > I goofed on #1. We should be using* org.ass
I like this API. I think it saves a lot of boilerplate, and a lot of subtle
possible mistakes. I think the new API would be a bit cleaner than the
RegionVersionVectorTest.doesNotHangIfOtherThreadChangedVersion that Kirk
mentions.
I would like to see generics, especially for `public void
runAndExp
Hi all,
I'm wondering what the collective's opinion of assertions is. I notice
there's an org.apache.geode.internal.Assert class, which is used some
places, and that plain old Java assertions are used in other places. Can we
remove one of these and use the other? Should we be including assertions
+1 to the new test organization.
And I agree with Patrick's explanation of which is the more stable test
category.
On Thu, Jun 28, 2018 at 9:47 AM, Patrick Rhomberg
wrote:
> @Dale
> It seems to me that the Unit / Distributed / etc would be the more stable
> purpose, and as importantly, each l
Hi Mike,
The attachment doesn't seem to have attached to your email.
Thanks,
Galen
On Wed, May 23, 2018 at 2:29 PM, Michael Stolz wrote:
> Can someone who has sufficient mojo please update the Apache Geode logo on
> geode.apache.org with the attached version with the TM added?
>
>
>
> --
> Mik
wrote:
Hi Galen,
I put a bunch of comments inline in your wiki page. One general question -
is the a proposal to change the default value encoding with the protobuf
protocol from JSON to this new format?
-Dan
On Wed, May 16, 2018 at 5:06 PM, Galen O'Sullivan
wrote:
Hi all,
Some of my coll
ot totally
fleshed out, so if there are details you can think of that we might have
missed or any other feedback you can give, I would love to hear it!
https://cwiki.apache.org/confluence/display/GEODE/Protobuf+Value+Encoding+Scheme+Proposal
Thanks,
Galen O'Sullivan
ps://dist.apache.org/repos/dist/release/geode/KEYS
[4] https://mirror-vm.apache.org/~henkp/checker/faq.html
On Apr 30, 2018, at 10:31 AM, Galen O'Sullivan wrote:
-1
I don't see Mike's key in the KEYS file on either rel/v1.6.0.RC1
(5ce726bd7b4f8d2648fd011a807a1bcc624ddfa5) or on dev
-1
I don't see Mike's key in the KEYS file on either rel/v1.6.0.RC1
(5ce726bd7b4f8d2648fd011a807a1bcc624ddfa5) or on develop.
It seems odd to me to add a new key and use it to sign the release
without using an already-existing key to sign the release as well. If
someone's trying to verify a
I'm for it. Less noise is a good thing, and I don't think they're likely
to get prioritized anyways. If we close as WONTFIX or similar, we can
always look back for them later if we want.
On 4/26/18 10:39 AM, Anthony Baker wrote:
Thanks Lynn!
As I first step I’d like to focus on issues labele
It looks like there are two classes called CacheElement in the codebase;
am I correct in thinking that you're referring to
org.apache.geode.cache.configuration.CacheElement?
This class doesn't have a Javadoc, so it's a little hard as an outsider
to understand exactly what it is or how it's use
It looks like there are a few JIRA tasks open to deprecate methods on
DistributedSystem, and it doesn't really have much functionality that would
be useful to a user. I propose that we deprecate DistributedSystem itself,
and keep the system management functionality internal. Is there any reason
why
Hi all,
We're working on a new protocol for Geode, which means wrapping Geode APIs
and exposing them via the new protocol. For performance and to avoid
class/serialization logic, we want to get these objects in serialized form.
This means calling cache.setReadSerializedForCurrentThread(true) while
Yeah, I think I'm sending myself convinced by Swapnil's argument.
How about muting the "nightly build succeeded" email?
On Wed, Mar 21, 2018 at 9:58 AM, Sean Goller wrote:
> Concourse sends mail whenever a job fails.
>
> On Wed, Mar 21, 2018 at 9:49 AM, Swapnil Bawaskar
> wrote:
>
> > I know t
On Tue, Mar 20, 2018 at 9:06 AM, Patrick Rhomberg
wrote:
>
> @Galen, I had thought it already did that.
>
I guess it does. I never knew. Excellent!
Hi all,
I'm wondering if it would be possible to have a separate list for commit
announcements, CI emails and similar automated messages, and keep this
mailing list for discussion. It would make it easier to filter email, and I
think it might help improve the discussion. I know I've missed message
+1 to all of the above.
Will Spotless also reorder imports according to our canonical ordering?
On Mon, Mar 19, 2018 at 4:17 PM, Sai Boorlagadda
wrote:
> +1
>
> On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund wrote:
>
> > +1
> >
> > On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg
> > wrote:
> >
Hopefully this will fix the pipeline failures. Sorry for the inconvenience.
Best,
Galen
Hi all,
I committed some code recently that looks like it broke the CI. However,
based on the failure, I think it will still fail if I revert the commit.
I'm currently testing a small hotfix and will apply it if it passes tests.
Sorry for the inconvenience.
Thanks,
Galen
GEODE-4836
https://githu
+1 for making the function service not static, and splitting servers from
clients.
Also +1 for Dan's suggestion.
On Wed, Mar 7, 2018 at 2:51 PM, Patrick Rhomberg
wrote:
> I did not know that! And then, yes, onRegion is much better.
>
> On Wed, Mar 7, 2018 at 2:43 PM, Dan Smith wrote:
>
> > >
gt; > if it isn't PDX-serialized? Do we return a byte array?
> > > >
> > > >
> > > > On 1/24/18 12:21 PM, Dan Smith wrote:
> > > > > Is this really just a workaround for the fact that the
> > read-serialized
> > > > flag
> &
Hi Addison,
What kind of setup do you have that is causing you to have PDX serialized
objects that cannot be deserialized? Do you have classes that are present
on some servers but not others?
This change would break the contract of region.get() , which is that it
returns a value of a type that ca
If you're talking about "Performance is Key. Consistency is a must", it
looks like the font is "Klavika Web Basic Light".
I see the following in the CSS for that element:
font-family: 'klavika-web', 'Open Sans', 'Helvetica Neue', Helvetica,
Arial, sans-serif !important;
On Mon, Nov 27, 2017 at 10
Can you show me the particular error? Does it persist? As far as I can
remember, we haven't changed that module this week.
On Fri, Nov 3, 2017 at 9:24 AM, Kirk Lund wrote:
> Precheckin last night failed to compile.
>
> On Fri, Nov 3, 2017 at 9:22 AM, Galen O'Sullivan
>
It may be that we missed one of the places where a module gets linked in.
Where did you see this error?
On Fri, Nov 3, 2017 at 9:20 AM, Kirk Lund wrote:
> Anyone know why the build is failing in geode-assembly?
>
> * What went wrong:
> A problem occurred evaluating project ':geode-assembly'.
> >
Yeah, it probably shouldn't be logging the whole stacktrace. I think we
should log a message at debug level, and log a warning if a new client
tries to connect when the new client protocol isn't available.
If we made a "geode-public-API" module, we could avoid the cyclic
dependency and do away wit
Hi all,
I'm thinking about the possibility of making a "Geode public API" module,
mostly containing interfaces that Geode implements.
Why would one do this, you may ask? Here are some reasons.
* It makes clear what is our public API (as opposed to "internal" type
packages).
* Users only have to
On Thu, Oct 5, 2017 at 3:14 PM, Jinmei Liao wrote:
> Not sure if this is useful to everyone, but when I push a subsequent commit
> to my feature branch, I always use "force push", so that it's only one commit
> I need to rebase to develop.
>
>
I use force push when I've made small changes and d
I don't care too much about exactly what the configuration looks like, but
I want it to be unified, and I want it to be set when the cache starts.
Checking system properties throughout the codebase whenever we feel like is
a bit too magic for me.
In addition, it seems that in order to add a new va
Currently, we have a setting for the new client protocol that controls
whether authentication is required or not. We expect to expand this in the
future, and also that there may be more configuration options for the
protocol. We would like to namespace the settings for this protocol but
don't reall
I'm having trouble running tests in IntelliJ because of errors with
compilation. Does anyone know why?
I've done a clean build and reloaded Gradle configuration in IntelliJ.
Thanks,
Galen
Information:java: Errors occurred while compiling module 'geode-core'
Information:javac 1.8.0_111 was used t
ark Bretl wrote:
> >
> > > The Apache Geode Project Management Committee has invited Galen
> > > O'Sullivan to join the Geode PMC and we are pleased to announce he has
> > > accepted.
> > >
> > > Please join me in welcoming Galen!
> > >
> > > Best regards,
> > >
> > > Mark
> > > On behalf of the Apache Geode PMC
> > >
> >
>
Replies inline.
On Mon, Sep 25, 2017 at 12:13 PM, Udo Kohlmeyer
wrote:
> Replies inline
> On Mon, Sep 25, 2017 at 11:21 AM, Dan Smith wrote:
>
> > This actually brings up another point I was going to ask about. I don't
> see
> > any version information in the protocol. How will we handle adding
We'll move everything to internal soon, before public release.
We have a ticket to fix the Javadocs and the links will be removed soon as
well. The broken links are for generated files that don't seem to have been
created when the javadoc task runs.
On Fri, Sep 22, 2017 at 2:27 PM, Dan Smith wro
+1 This is great! I'll take a look at your PR when I get the time.
We may want to think carefully about how often we run these tests, because
unlike regular unit tests, they will take forever to run.
On Fri, Sep 15, 2017 at 1:42 PM, Michael William Dodge
wrote:
> +1 for unit tests for multithre
Hi all,
I like to run a `./gradlew clean build` when I'm pulling, reviewing, or
about to push a new build. It seems that this causes the cached geode zip
files to have to be redownloaded, which means that the build takes 10
minutes instead of 2. If I'm touching a couple of branches a day, this can
Looks like the repos have moved to gitbox. It should be as simple as
changing the three git-wip-us.apache.org links to gitbox.apache.org .
On Tue, Sep 5, 2017 at 5:01 PM, Karen Miller wrote:
> A guarded +1 based on limited testing of the RC:
>
> Built the Geode RC from source.
> Built and ran t
think `allow`
would be clearer than `disallow` because it avoids double-negatives. Can we use
`allow-internal-messages-without-credentials` and have it default to `true`?
- Galen O'Sullivan
On Sept. 5, 2017, 5:57 p.m., Bruce Schuchardt
It looks like it's moved. If you go to the URL in a browser it will give
you a hint. This command should work to update your remote:
git remote set-url
https://gitbox.apache.org/repos/asf/geode.git
running `git remote -v` after should confirm the change.
On Fri, Sep 1, 2017 at 2:30 PM, Bruce S
nt260549>
This comparison is changed with byte vs int rules. Probably better to use
the int comparison.
Thismight be even better as a method implemented on CommunicationMode.
- Galen O'Sullivan
On Aug. 30, 2017, 8:48 p.m., Bruce
I just filed GEODE- for GMSJoinLeaveJUnitTest.
testViewNotSentWhenShuttingDown . I've gotten a failure from the command
line, but not when I run it from within IntelliJ (even repeatedly).
On Fri, Jul 28, 2017 at 4:12 PM, Bruce Schuchardt
wrote:
> (GEODE-3155) GMSJoinLeaveJUnitTest.testCoordi
I have had a lot of tests fail because mcast-port is nonzero. So now I set
that system property in a lot of new tests. Maybe the tests that set it to
something other than the default should be passing a Properties object to
CacheFactory rather than messing with system properties.
I think the Cache
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60834/#review180546
---
Ship it!
Ship It!
- Galen O'Sullivan
On July 13, 201
What's the general opinion of @NotNull annotations? Would they be useful?
On Fri, Jul 14, 2017 at 9:23 AM, John Blum wrote:
> +1 as well.
>
> However, I will caution this... use Java 8's new java.util.Optional class
> in your codebase judiciously. Using it everywhere, especially on critical
> c
me that you're going to a lot of work to make the mock here.
Would a spy be easier to understand?
geode-protobuf/src/test/java/org/apache/geode/protocol/protobuf/operations/PutAllRequestOperationHandlerJUnitTest.java
Lines 68 (patched)
<https://reviews.apache.org/r/60718/#comment255537>
64>
I'm not all that familiar with backwards compatibility tests, but do we
want to be testing agains current version and testing version or current and
9.0? Will backwards compatibility set `testVersion` to 9.0 among other version
keep builds from failing.
Diffs
-
geode-assembly/src/test/resources/expected_jars.txt 62601677f
Diff: https://reviews.apache.org/r/60550/diff/1/
Testing
---
Built on my machine, verified that the test passes.
Thanks,
Galen O'Sullivan
> On June 27, 2017, 6:19 p.m., Galen O'Sullivan wrote:
> > The diff doesn't apply cleanly on develop on my machine. What's the base
> > commit?
Or better, can you merge or rebase on develop please?
- Galen
--
hat's the base commit?
geode-assembly/build.gradle
Lines 143 (patched)
<https://reviews.apache.org/r/60312/#comment253398>
It's a nit, but it would be nice to remove trailing whitespace.
- Galen O'Sullivan
On June 21, 2017, 9:35 p
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60442/#review179007
---
Ship it!
Ship It!
- Galen O'Sullivan
On June 26, 2017,
pache/geode/internal/cache/ha/ThreadIdentifierJUnitTest.java
Lines 40 (patched)
<https://reviews.apache.org/r/60446/#comment253364>
Is it possible for a Membership ID to be less than 17 bytes and this to be
negative?
- Galen O'Sullivan
On June 26, 2017, 10:24 p.m.,
afcc6
gradle/rat.gradle 1bea5843b
settings.gradle c0fdb6e4f
Diff: https://reviews.apache.org/r/60394/diff/2/
Testing
---
Precheckin passed on v1 (with the serializable in `excludeClasses.txt` instead
of `sanctionedSerializables.txt`).
Thanks,
Galen O'Sullivan
settings.gradle c0fdb6e4f
Diff: https://reviews.apache.org/r/60394/diff/2/
Changes: https://reviews.apache.org/r/60394/diff/1-2/
Testing
---
Precheckin passed on v1 (with the serializable in `excludeClasses.txt` instead
of `sanctionedSerializables.txt`.
Thanks,
Galen O'Sullivan
`excludeClasses.txt` instead
of `sanctionedSerializables.txt`.
Thanks,
Galen O'Sullivan
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60217/#review178541
---
Ship it!
Ship It!
- Galen O'Sullivan
On June 21, 2017,
-
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60217/
> ---
>
> (Updated June 21, 2017, 12:02 a.m.)
>
>
> Review request for geode, Alexander Murmann, Bruce Schuchardt,
reviews.apache.org/r/60217/#comment252365>
Do you know what this ignore does?
geode-protobuf/src/test/java/org/apache/geode/serialization/registry/CodecRegistryJUnitTest.java
Lines 58 (patched)
<https://reviews.apache.org/r/60217/#comment252367>
This test can have an expected e
;ve
only gotten the one key. It's not a lot of benefit, though.
settings.gradle
Line 39 (original), 39 (patched)
<https://reviews.apache.org/r/60217/#comment252339>
`geode-protobuf` will also need to be added to `geode-assembly` before this
is functional, but we can do that in
, but I'd consider
it pretty much equivalent. If you want me to run again, I will.)
Thanks,
Galen O'Sullivan
il. To reply, visit:
https://reviews.apache.org/r/60157/#review178279
---
On June 20, 2017, 12:53 a.m., Galen O'Sullivan wrote:
>
> ---
> This is an automatically generated
t; > <https://reviews.apache.org/r/60157/diff/2/?file=1752476#file1752476line58>
> >
> > surely we don't need this here... How do we handle the case if we have
> > another client protocol handler... this would fail.
We can test this at the factory level. I ha
much equivalent. If you want me to run again, I will.)
Thanks,
Galen O'Sullivan
will.)
Thanks,
Galen O'Sullivan
I'd consider
it pretty much equivalent. If you want me to run again, I will.)
Thanks,
Galen O'Sullivan
> ---
>
> (Updated June 8, 2017, 12:20 a.m.)
>
>
> Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen
> O'Sullivan, Hitesh Khamesra, and Brian Rowe.
>
>
> Repository: geode
>
&
1 - 100 of 227 matches
Mail list logo
