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
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52052/#review149759
---
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
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
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
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.
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
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?
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
---
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
---
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
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:
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
> 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
14 matches
Mail list logo