Spring Data Geode 1.0.0-INCUBATING-RELEASE available!

I am happy to announce the release of *Spring Data* for *Apache Geode* 1.0.0-incubating, which marks the first, official GA release of *Apache Geode* as well as the first GA release of SDG to match. One of the key themes of this release is *security*. Currently, *Apache Geode* builds on *Apache

Re: Improving release notes

Yes, +1. Also, it doesn't hurt to list the significant/critical dependency updates in a subsection. -j On Thu, Oct 27, 2016 at 3:10 PM, Anthony Baker wrote: > The release notes [1] from the latest release announcement [2] included a > long list of all the JIRA’s associated

Re: Review Request 53168: GEODE-2030: security support for SDG

from changing what they return vs. throw. I think this looks pretty good overall. This will definitely help with configuring and using Apache Geode's Integrated Security (framework) in different contexts (Spring, PCF, and even simple testing). - John Blum On Oct. 25, 2016, 3:34 p.m.,

Re: Hosting the docs (was Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating - RC2)

Perhaps longer term we should consider moving the docs to Asciidoc It is relatively simple matter to convert Asciidoc to PDF. On Tue, Oct 18, 2016 at 1:42 PM, Jared Stewart wrote: > Sadly just looked at the license for wkhtmltopdf and it uses GPL 3.0. I > believe that

Re: GEODE-1466: geode.properties

-1 for introducing this change as well. Also -1 for introducing any additional constants/workarounds. Either fix it the way it should be fixed or do nothing at all. On Thu, Oct 13, 2016 at 2:45 PM, Kirk Lund wrote: > -1 at this point I'm against making this change for 1.0.0

Re: Deprecate DynamicRegionFactory

+1 - forget deprecated; delete it. On Tue, Oct 11, 2016 at 8:22 PM, Udo Kohlmeyer wrote: > +1 - I see no real benefit for this. > > > > On 12/10/16 1:10 pm, William Markito wrote: > >> +1 - We always discouraged people using dynamic regions >> >> On Tue, Oct 11, 2016 at

Re: Assert usage in geode-core

If this is the case, I would encourage the use of a fluent API, e.g. *AssertJ's* assertions, to replace *Spring* core's capable Assert [1] class. Resorting back to the ugly and often brittle conditional

Re: CI bugs

+1 On Tue, Oct 4, 2016 at 10:11 AM, Kirk Lund wrote: > Please don't close flaky tickets or remove FlakyTest category unless you > know of a specific commit revision that makes some timing changes to the > test. Unless you replace all the Thread.sleeps with await() calls it's >

Re: How to change log level

Hi Goutam- > Can we change it through gemfire.properties ? No However, you can use the *Gfsh* 'alter runtime' command, for instance... gfsh>alter runtime --log-level=config If you just want to change a specific members log-level then... gfsh>alter runtime --log-level=config --member=Server1

Re: Podling Report Reminder - October 2016

Dan- Luke and I also presented at *SpringOne*, talking about Apache Geode; see here... https://2016.event.springoneplatform.io/schedule/sessions/spring_data_and_in_memory_data_management_in_action.html *Brain Dunlap* from *Southwest Airlines* also talked (

Re: security properties in the cluster config

Jinmei- Where are the following security-* properties documented? security-udp-dhalgo security-manager security-post-processor They certainly are not documented in the (Geode) User Docs, here [1]. Thanks! John [1]

Re: jvsd

+1 Even a bit of documentation (which seems scattered about... in the specification, on VMW sites/properties, etc) would go a long way in helping users realize the benefit of the tool and provide feedback, maybe even contribute some PRs. Having metrics on GemFire in realtime is hugely invaluable

Re: jvsd

Who are you "end users"? On Thu, Sep 22, 2016 at 7:37 PM, Anthony Baker wrote: > When the first instruction is `git checkout feature/GEODE-78` I think it’s > clear the target audience is not end users. > > Beyond that, it feels to early to document a feature whose final form

Re: jvsd

elease, at which time it > should also be documented in the user guide). > > > On Thu, Sep 22, 2016 at 5:30 PM John Blum <jb...@pivotal.io> wrote: > > > And by Wiki, I mean GitHub's Wiki associated with the (source code) > > Repository. Between GitHub Wiki and README, RE

Re: jvsd

And by Wiki, I mean GitHub's Wiki associated with the (source code) Repository. Between GitHub Wiki and README, README wins every time for reason previously mentioned. On Thu, Sep 22, 2016 at 5:28 PM, John Blum <jb...@pivotal.io> wrote: > Personally, as a engineer, I am more

Re: jvsd

bar...@pivotal.io > > <javascript:;> > > > > <javascript:;>> wrote: > > > > > > > > > Process for handling Experimental docs is still being hammered out. > > > > Common > > > > > element among working scenarios is i

Re: jvsd

Truthfully, I don't think this is any different than API features that have been annotated with "@Experimental" (e.g. LucenceService ). I.e. nothing is going to stop a user from trying

Re: securing geode components

I agree with Udo here. Securing the channel between component/services has really very little to do with Authentication/Authorization, and by "Authentication", I mean in the user-centric sense, not the SSL "trusted" sense (with "trusted" keys and such). Whether a user can or cannot do something

Re: json-path-assert for json related unit tests

+1 to standardizing Geode on Jackson for JSON processing. +1 to using JsonPath/json-path-assert for testing interactions in Geode on JSON docs. On Thu, Sep 8, 2016 at 10:22 AM, Kirk Lund wrote: > Yes, we should change all json parsing code to use jackson. However, we > still

Re: Review Request 51618: GEODE-1836: remove defunct Java 1.6 block for Mac from GFSH script

y form of file system paths (especially absolute paths) in a given OS for a particular bit of software (e.g. JDK or other) is dangerous and always subject to change. - John Blum On Sept. 2, 2016, 10:48 p.m., Kirk Lund

Re: M3 is done, what's next?

+1 for making changes sooner rather than later. Also, thank you Dan for mentioning this effort will need to coordinated with *Spring Data Geode*. On Fri, Sep 2, 2016 at 10:39 AM, Darrel Schneider wrote: > +1 for renaming the packages > > > On Fri, Sep 2, 2016 at 9:57 AM,

Re: Experimental features for 1.0

Yep, were good... Thanks William! On Fri, Aug 12, 2016 at 12:10 PM, William Markito <wmark...@pivotal.io> wrote: > I've just updated it, can you please try again ? > > Thanks > > On Fri, Aug 12, 2016 at 11:30 AM, John Blum <jb...@pivotal.io> wrote: > > > Hi Wi

Re: Experimental features for 1.0

Hi William- Says your filter does not exist or is private, even when logged in. Thanks, -John On Fri, Aug 12, 2016 at 11:22 AM, William Markito wrote: > Here is the initial list of JIRA's... > > https://issues.apache.org/jira/issues/?filter=12338213 > > This might be a

Re: Experimental features for 1.0

+1 What about HDFS storage support, or was this dropped completely? On Wed, Aug 10, 2016 at 6:12 PM, Joey McAllister wrote: > +1 - Great idea > > On Wed, Aug 10, 2016 at 6:10 PM Michael Stolz wrote: > > > Yes we should definitely do this > > > > -- >

Re: Array of primitives as region values

Just tried with several other value-class type specifiers; same Exception. On Thu, Jul 28, 2016 at 11:54 PM, John Blum <jb...@pivotal.io> wrote: > Hi Jinmei- > > Yes, I have confirmed the same thing. I have tried specifying a > value-class (type) information, but that d

Re: Array of primitives as region values

Hi Jinmei- Yes, I have confirmed the same thing. I have tried specifying a value-class (type) information, but that did not work either... gfsh>debug --state=ON Debug is ON gfsh>get --region=/Example --key=key1 --value-class=J[java.lang.Integer.TYPE;Exception occurred. null

Re: Goede Clubhouse Meeting in August...

like important work to talk to the Geode Community about. > > > > I'm happy to host you! I'll create a calendar event! > > > > -Greg > > > > On Thu, Jul 28, 2016 at 6:22 PM, John Blum <jb...@pivotal.io> wrote: > > > >> Hi All- > >> > >

Goede Clubhouse Meeting in August...

Hi All- Recently, I have made significant progress on new developments in *Spring Data GemFire* as well as *Spring Data Geode's* new Java annotation-based configuration meta-data approach. My promise is this, this will greatly simplify the user's getting started experience when developing

Re: use-cluster-configuration/cache.xml/reconnect

For *Spring (Data GemFire)* applications, I don't strictly refuse this configuration, as it is a valid configuration. It's just *not* enabled by *default* since most *Spring* configured members (GemFire peer cache) are "applications" that use the GemFire components/objects (Cache, Regions, etc)

Re: Proposal - Fail cache creation on persistent PR colocation misconfiguration

Ah, I see, thanks Dan. On Mon, Jul 25, 2016 at 1:03 PM, Dan Smith <dsm...@pivotal.io> wrote: > On Mon, Jul 25, 2016 at 12:19 PM, John Blum <jb...@pivotal.io> wrote: > > > *> The issue is that even though you have everything defined in > cache.xml, > >

Re: Proposal - Fail cache creation on persistent PR colocation misconfiguration

*> The issue is that even though you have everything defined in cache.xml, if you have manual-start set to true on the gateway it will not create the colocated regions until you call start* Why is that? I am not sure I understand why collocated (child) *Regions* would not be (or prevented from

Re: use-cluster-configuration/cache.xml/reconnect

Hi Kirk- FYI, SDG disables [1] *cluster config*, and especially, *auto-reconnect* by default. Having a peer cache "application" configured

Re: How to execute a Partition Region join in a Function context...

((RegionFunctionContext)context)*; Thanks, John On Tue, Jul 12, 2016 at 6:54 PM, John Blum <jb...@pivotal.io> wrote: > Thanks for the fast response Dan. > > Unfortunately, that did not work, given the following... > > protected static final String CUSTOMERS_WITH_CONTACTS

How to execute a Partition Region join in a Function context...

I have 2 PRs (Customers & Contacts) and I am running a query to find all customers with contact information. I have collocated both Customers and Contacts. Initially, I tried to run the query outside a GemFire Function, which failed with... java.lang.UnsupportedOperationException: *A query on a

Re: Spring Boot and Apache Geode

nting with Geode clients and I'd like to try Spring Boot. > > For Mac users, it might be good to clarify adding java as a firewall > exception. > I had connection issues when I ran a separate locator and server. > > Brian - > > On Tue, Jun 21, 2016 at 8:26 PM, John Blum <jb...@p

Spring Boot and Apache Geode

Want to know how to connect a Spring Boot configured and bootstrapped Apache Geode server to an existing Geode cluster, then check this out... https://github.com/jxblum/spring-boot-gemfire-server-example All references to Pivotal GemFire can be replaced with Apache Geode. Any questions or

Re: update website for WAN, CQ and native client

+1 On Tue, Jun 21, 2016 at 11:43 AM, Swapnil Bawaskar wrote: > Take 3: http://i.imgur.com/VUQRw4u.png > 1. Replaced Redis logo with http://fontawesome.io/icon/plug/ > 2. Changed WAN to Multi-Site. > > Thanks! > Swapnil. > > On Sat, Jun 18, 2016 at 7:22 PM, theseusyang

Re: update website for WAN, CQ and native client

+1 to "multi-site" (maybe even augmented with, dare I say "replication"), though I personally don't have a problem with WAN. Of course, that might seem dated, but then I am getting older, ;-) Perhaps WAN with a short description.. "Multi-Site Replication for Active/Active, Active/Passive (DR),

Re: update website for WAN, CQ and native client

@Swap- Perhaps we should mention Geode also supports *Redis* and *Memcached* clients (through the respective protocols) as well, though we do not develop dedicated clients for either. Thoughts on how to best represent that? -John On Thu, Jun 16, 2016 at 5:51 AM, Jacob Barrett

Re: DistributionConfig and Geode system properties

Perhaps the (interface) name can be simplified to ConfigurationProperties too. Not all properties necessarily involve specifically the distributed system configuration, but rather the overall Geode system configuration (Cache, Management, HTTP Service(s), Clients, etc). On Thu, Jun 2, 2016 at

Re: Review Request 47145: GEODE-1370: fix SDG by renaming SharedConfiguration.destroySharedConfiguration_forTestsOnly back to destroySharedConfiguration

with this method, combined with additional initialization logic, it proved unreliable during subsequent forked Locator restarts. - John Blum On May 10, 2016, 12:25 a.m., Kirk Lund wrote: > > --- > This is an automatically generat

Spring Data Geode 1.0.0.APACHE-GEODE-INCUBATING-M2 Released

://spring.io/blog/2016/04/29/spring-data-geode-1-0-0-apache-geode-incubating-m2-released https://twitter.com/john_blum/status/726195512051814401 Feedback welcomed. Thank you, John Blum

Re: [Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #288 has FAILED

stand why those old snapshots are still there. > > In any case, it doesn't make sense to build off of M2 snapshots at > this point because M2 is no longer under development. Either use the > actual M2 release or the M3 snapshots. > > -Dan > > On Sun, Apr 24, 2016 at 1:14

Re: Comparing maven deps vs lib/ dir

+1 This is a huge improvement; nice work! Not sure about all them, but I seem to remember the log4j extension JARs (e.g. log4j-jcl, log4j-jul and log4j-slf4j-impl) definitely being feature specific. I think it was *Gfsh* that used JUL and embedded Tomcat (at the time) that used SLF4J.

Re: Jira ticket workflow

I think it makes the most sense to "close" after the ticket goes out in a release. On Tue, Apr 12, 2016 at 10:33 AM, Dan Smith wrote: > When you finish a ticket and push it to develop, mark the ticket as > resolved and set the "Fix Version" to the upcoming release. Right now

Re: Bundled jar dependencies

I would not include the (javax.)servlet-api JAR with Geode. It will be a significant pain point for web applications (and frameworks, e.g. *Spring Session*) that expect a specific version of the Servlet API and then suddenly encounter conflicting versions. Also, FYI, the latest release of the

Re: Review Request 45509: GEODE-1025: Removing bundled SDG and special handling of spring jars

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45509/#review127237 --- Ship it! Everything else looks good. - John Blum On April 5

Re: Review Request 45509: GEODE-1025: Removing bundled SDG and special handling of spring jars

> On April 5, 2016, 10 p.m., John Blum wrote: > > geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java, > > line 1146 > > <https://reviews.apache.org/r/45509/diff/2/?file=1326856#file1326856line1146> > >

Re: Review Request 45509: GEODE-1025: Removing bundled SDG and special handling of spring jars

with Spring using Gfsh. gradle/dependency-versions.properties (line 88) <https://reviews.apache.org/r/45509/#comment190402> Again, I don't think this is needed either. - John Blum On April 5, 2016, 9:

Re: Removing hydra.Log from dunit tests

t > for some reason. But I also agree with Kareem that the tests generally > shouldn't have log statements unless you are trying to debug the test. > > -Dan > > On Tue, Apr 5, 2016 at 11:05 AM, John Blum <jb...@pivotal.io> wrote: > > > +1 I know when you set GemFire's l

Re: Removing hydra.Log from dunit tests

+1 I know when you set GemFire's log level to "config", it can take the tests much longer to run, and it consumes more resources. As far as logging approach, using an actual "Logger" makes the most sense in order to control what gets logged along with the level of detail. System.out's are much

Re: RestAPIsWithSSLDUnitTest fails

es work better but it has duplicates of httpclient and httpcore. > > > On Wed, Mar 23, 2016 at 1:45 PM, John Blum <jb...@pivotal.io> wrote: > > > I.e. ... "File" -> "New" -> "Project from Existing Sources..." -> > your Geode working

Re: RestAPIsWithSSLDUnitTest fails

sclaimer: I have not tried this recently, but I usually have more success going this route. -John On Wed, Mar 23, 2016 at 1:40 PM, John Blum <jb...@pivotal.io> wrote: > Kirk- rather than have Gradle generate the .idea project files, have you > tried importing the Geode project from exis

Re: RestAPIsWithSSLDUnitTest fails

sorts of stuff for gfsh, pulse, the REST API, etc. GEODE-818 is all > > about cleaning that up. I was hoping to take up GEODE-1072 (remove HDFS > > code) when I get a chance. If you want to clean up the dependencies > please > > chip in and take on some of those subtasks, the sooner t

Re: RestAPIsWithSSLDUnitTest fails

ng with gradle and dependency > versioning and wondering why intellij is picking up 2 versions of jna, 3 > versions of apache http, etc. > > -Kirk > > > On Wed, Mar 23, 2016 at 11:04 AM, John Blum <jb...@pivotal.io> wrote: > > > In a nutshell, you want the dependencies and a

Re: RestAPIsWithSSLDUnitTest fails

In a nutshell, you want the dependencies and all the transitive dependencies versions to agree, otherwise conflicts like what Kirk experienced, as well as what I experienced while integrating Apache Geode support into Spring Session, will occur, and users will have problems using Geode in

Re: Can we close GEODE-36 ? (Gfsh renaming)

+1 On Wed, Mar 16, 2016 at 7:19 AM, Anthony Baker wrote: > +1 > > I think Geode Fabulous SHell is a reasonable name. Changing it generates > a ton of work both in the code and documentation without much benefit IMO. > > Link to the original discussion: > >

Re: Review Request 44242: GEODE-1025: Replacing direct dependency on spring data gemfire with an SPI

unecessary default constructor, especially since it only contains a TODO and no actual initialization logic. - John Blum On March 2, 2016, 12:57 a.m., Dan Smith wrote: > > --- > This is an automatica

Re: Reminder: include GEODE-xxx jira ticket # in commit message

th the Apache Way to open a single JIRA ticket > for > >> 'doc typo repair,' keep it open, and re-use it over and over? > >> That would spare us from creating dozens of identical JIRA tickets that > >> differ only by number. > >> > >> > >>

Re: Reminder: include GEODE-xxx jira ticket # in commit message

On Spring projects, and in particular, Spring Data GemFire, we file JIRA tickets and categorize them as "tasks". However, it not uncommon for a bug (fix)/enhancement/new-feature to have code/test/documentation changes all filed under a single JIRA. For example... SGF-123 - Improve feature X...

Configuring client/server topologies using Spring or GemFire config...

I have been working on a customer GemFire issue for State Farm and recently put together a project containing a few example applications that show how to properly configure a GemFire client and server cache topology using both Spring config as well as GemFire's native config. If you are working

Spring Data GemFire support for Apache Geode 1.0.0-incubating.M1

However, you no longer need to declare the Apache Maven Snapshots Repository (@https://repository.apache.org/content/repositories/snapshots) in your POM file because, as Nitin explained, Apache Geode 1.0.0-incubating.M1 is available in Maven Central... Yay! Happy coding peeps! -John Blum

Re: [DISCUSS] Next Release Scope - version 1.0.0-incubating.M2

https://github.com/spring-projects/spring-data-gemfire/blob/master/build.gradle#L64-L104 [4] - https://repo1.maven.org/maven2/org/springframework/data/spring-data-gemfire/1.7.2.RELEASE/spring-data-gemfire-1.7.2.RELEASE.pom On Tue, Feb 9, 2016 at 7:23 PM, John Blum <jb...@pivotal.io&g

Re: [DISCUSS] Next Release Scope - version 1.0.0-incubating.M2

r working through this. Great suggestions! > > Anthony > > > On Feb 10, 2016, at 8:21 AM, John Blum <jb...@pivotal.io> wrote: > > > > Following up... > > > > I spent a few extra cycles researching the *Apache Geode* dependencies > > further. > >

Re: [DISCUSS] Next Release Scope - version 1.0.0-incubating.M2

Here is an example of a (possible) *dependency conflict* caused by *Apache Geode* requiring a different version of Jackson than is pulled in by HBase, which also has a dependency on Jackson, where HBase is a also dependency of *Apache Geode*. This dependency graph comes from *Spring Data GemFire*

Re: 1.0.0-incubating.M1

I was thinking about this and I am tempted to leave *Spring Data GemFire* with *Apache Geode* support (apache-geode) on build snapshots until the first official (GA) release. Typically, Spring projects do not consume dependencies unless those dependencies are GA versions. We could, in effect,

Re: [DISCUSS] Next Release Scope - version 1.0.0-incubating.M2

Technically, GEODE-27 [0] was less about the format and more about fixing the POM so it is correct. Revising my earlier comments (in the JIRA), the repository declarations

Re: gemfire-modules-session compile failures

mavenLocal() should definitely *not* be in the repositories { ... } declaration [0] of build.gradle. I am actually quite surprised this passed either the Apache or Sonatype's release process. Sonatype

Re: [VOTE] RC2: Apache Geode (Incubating) first Milestone release - v1.0.0-incubating.M1

+1 I would also add, in addition to what Dan mentioned, that GEODE-27 get fixed sooner rather than later. I recently completed the Spring Session GemFire support and went ahead to add support for Apache Geode as well. I can definitely say it was nothing short of a nightmare to integrate given

Re: Client/Server?

re the server starts, it waits in > waitForServer. Once the server starts, it gets notified and continues. If I > start the TestClient after the server starts, it just sails through the > waitForServer. > > > Barry Oglesby > GemFire Advanced Customer Engineering (ACE) > For immediate s

Re: Client/Server?

shipListener(com.gemstone.gemfire.management.membership.ClientMembershipListener) [1] - https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/InternalClientMembership.java#L369-L393 On Wed, Jan 20, 2016 at 6:59 PM, John Blum <jb...@pivotal.io> wrote: > Hi

Re: Client/Server?

rs. It only works if you have > a locator, and it uses some java public (but not Geode public) API. This > API can be used by the client to determine how many servers there are and > their locations. I can point you to that if you're interested. > > > Barry Oglesby > GemFire Advanced

Re: Geode versions in Jira tickets

king > fixes that will probably be in a .M2 release, but there is no .M2 in JIRA > yet. > > -Dan > > On Wed, Jan 20, 2016 at 10:22 AM, John Blum <jb...@pivotal.io> wrote: > > > With Spring projects, we use "affects" version that an issue was reported > > i

Client/Server?

Is there a recommended, (more) reliable means to determine whether a CacheServer (listening for cache clients) has successfully started in a GemFire server from the client-side? Currently, I am employing a form of inter-process communication (e.g. control file) to coordinate the successful

Re: A few recommendations on how to produce our first RC

Hmm, interesting. I guess the main difference is in how we are defining a "release candidate". With Apache, it would seem release candidates are used to start a process to determine whether a project at it's current version (e.g. 1.0.0.M1) is in a releasable state, as voted on by the PMC.

Re: A few recommendations on how to produce our first RC

On Wed, Jan 13, 2016 at 5:38 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > On Wed, Jan 13, 2016 at 5:33 PM, John Blum <jb...@pivotal.io> wrote: > > *> So I think the real question to ask of Spring folks is this: do > > they expect Mx and RCx artifacts to

Re: A few recommendations on how to produce our first RC

tifacts to be consumed by general public? > > Thanks, > Roman. > > On Wed, Jan 13, 2016 at 1:23 PM, John Blum <jb...@pivotal.io> wrote: > > Hmm, interesting. I guess the main difference is in how we are defining > a > > "release candidate". &g

Re: releaseType?

uot;RC" in the version of > an > > official ASF release (e.g. "1.0.0-RC1") - if thats the case it > could/would > > be published to the public Maven repo and advertised outside the dev > > community. > > > > Niall > > > > > >&

Re: releaseType?

In Spring, the releaseType (qualifier) is always (BUILD-)SNAPSHOT unless it is a release (M1, M2, ..., RC1, ... RELEASE (GA)). When a particular version ends, for instance when 1.0.0.RELASE goes GA, the version/releaseType switches to 1.1.0.(BUILD-)SNAPSHOT and a 1.0.x branch is created to

Re: Open pull requests

True, the graph definitely, but the commit messages, not so much. On Fri, Jan 8, 2016 at 9:38 AM, Kirk Lund <kl...@pivotal.io> wrote: > That's probably caused by the fact that many of us are just learning git. > > -Kirk > > > On Fri, Jan 8, 2016 at 9:34 AM, John Blum

Re: Can we change JIRA notifications?

+1 On Fri, Jan 8, 2016 at 5:26 PM, Jacob Barrett wrote: > In line with William's request to limit the JIRA emails on feature > branches, can we change the notification model for all JIRAs to something > less frequent. > > Only have the initial create notification go to the

Re: releaseType?

t; I do think we should remove the -SNAPSHOT from the version on the release > branch so that we can validate the exact bits that we will publish. Also, > I don’t see a need to do M? or RC? releases before this initial release. > IMHO of course... > > Anthony > > > > On Jan 8,

Re: Open pull requests

s on > https://github.com/apache/incubator-geode to close any PRs manually. The > only way I know of to close them is via a commit that includes "Closes #38" > in the commit message and then the asfgit bot closes it for us. > > -Kirk > > > On Fri, Jan 8, 2016 at 9:17

Re: Open pull requests

You don't need to push commits to close PRs (at least not in GitHub; not sure how Apace works). On Fri, Jan 8, 2016 at 9:14 AM, Kirk Lund wrote: > Since #36 and #38 were already merged into develop via #42, should I closed > them with two separate empty commits or is there a

Re: Open pull requests

I just clarify, when you push the "patch" associated with the PR (if done properly) it will automatically close the PR. If not done properly, then you can manually close it without a commit. On Fri, Jan 8, 2016 at 9:16 AM, John Blum <jb...@pivotal.io> wrote: > You don't n

Re: Propose new committer - Jinmei Liao

Anyone who is capable of contributing sensible/quality changes, especially to Apache Geode, as well as earned the trust of the other Geode committers, has my vote. +1 to Jinmei as a committer. On Wed, Jan 6, 2016 at 10:21 AM, Roman Shaposhnik wrote: > On top of great

Re: Propose new committer - Jinmei Liao

ou are not on priv...@geode.incubator.apache.org, you > should sign up (with your apache id) since you are an initial committer to > geode. There is a thread on that list regarding the proposal. > > -Dan > > On Thu, Jan 7, 2016 at 9:37 AM, John Blum <jb...@pivotal.io> wrote: &

Re: Deprecating subregions

+1 to deprecating Subregions. On Thu, Jan 7, 2016 at 10:41 AM, Jens Deppe wrote: > In the past (GemFire days) we've had discussions about deprecating > subregions. I'd like to raise the topic again for consideration. > > Subregions are merely a way to provide a logical,

Re: New Geode website - Latest changes

Nice work William! +1 In case anyone has problems viewing the new site, just refresh your browser. Some browsers (e.g. Chrome) may cache the old content (mine did). On Tue, Dec 8, 2015 at 5:02 PM, William Markito wrote: > All done. geode.incubator.apache.org is

Re: Regarding integrated security - GEODE-17

+1 for Spring Security On Fri, Dec 4, 2015 at 9:36 AM, William Markito wrote: > Huge +1 for using Shiro / Spring Security and moving to a standard security > model. > > On Fri, Dec 4, 2015 at 9:33 AM, Jens Deppe wrote: > > > Greetings. > > > > A while

Re: Geode's use of JSON libs

+1 for Jackson. org.json was used because the developers of M responsible for this functional area using org.json decided it was an easier API to learn/use. As it turns out, org.json is too crude for most practical use cases. On Thu, Dec 3, 2015 at 6:50 AM, Jens Deppe wrote:

Re: Question on Querying and PDX Serialization

No. JSONFormatter only works between JSON and PDX. As such, the REST API does not support Java serialization OOTB. On Thu, Dec 3, 2015 at 11:31 AM, Nikhil Chandrappa wrote: > Thanks everyone for the response. Seems like enabling the PDX on the > client cache is way to

Re: JIRA Resolved vs Closed

+1 To add a bit of clarification on the Resolved vs. Closed status, you can also think of Closed as the moment the customer/user considers the issue/enhancement identified in the JIRA as complete and "accepted". Since most OSS projects do not have a specific user/customer, then a ticket is

Re: Geode Definition of Done (DOD)

+1 On Mon, Nov 2, 2015 at 12:36 PM, Udo Kohlmeyer wrote: > +1 > On 3 Nov 2015 7:14 am, "Kirk Lund" wrote: > > > I think we need to settle on a formal Definition of Done (DOD) for Apache > > Geode. Again, borrowing from Spring Data we could start with

Re: Geode Definition of Done (DOD)

. > > Anthony > > > > On Nov 2, 2015, at 1:33 PM, William Markito <wmark...@pivotal.io> wrote: > > > > +1 > > > > Just one question, what is snapshot build deployed ? Is it the same as > > snapshot build successfully completed ? > > > &

Re: Bump language level to 1.8

+1 However, just a reminder, most environments (e.g. Java EE application servers: WebSphere, WebLogic, etc) where GemFire/Geode will most likely be used (in the enterprise) are still largely based on a 1.6 runtime, especially older versions that are still predominantly in production. In

Re: Review Request 39023: GEODE-381 enable gfsh https usage through SSL terminated environments

6) <https://reviews.apache.org/r/39023/#comment161700> Make the "scheme" parameter final for consistency. gemfire-web/src/test/java/com/gemstone/gemfire/management/internal/web/controllers/ShellCommandsControllerJUnitTest.java (line 215) <https://reviews.apache.org/r/3902

Re: Review Request 39023: GEODE-381 enable gfsh https usage through SSL terminated environments

"unit" tests). On Thu, Oct 22, 2015 at 2:06 PM, John Blum <jb...@pivotal.io> wrote: > So to be clear, the Management REST API has it's own set of test classes > for "unit" tests. When it comes to integration testing, I took advantage > of the fact the Management

Re: Review Request 39023: GEODE-381 enable gfsh https usage through SSL terminated environments

; of configuration to use HTTP REST instead of JMX RMI. In this way, the > > same > > > test would be executed but configured in a different way. > > > > > > -Kirk > > > > > > > > > On Thu, Oct 22, 2015 at 1:35 PM, John Blum

Re: Is REST APIs test coverage missing in geode codebase?

Answers and comments in-line below... On Fri, Oct 9, 2015 at 1:07 PM, Nitin Lamba wrote: > Hi, > > Trying to revive this thread after a few months - does the Developer REST > APIs have any tests, like those included in Management REST APIs? > Yes. In the original, "closed"

  1   2   >