Passed: apache/geode-native#2119 (rel/v1.10.0 - 0668f6b)

Build Update for apache/geode-native - Build: #2119 Status: Passed Duration: 1 hr, 34 mins, and 37 secs Commit: 0668f6b (rel/v1.10.0) Author: Owen Nichols Message: GEODE-7182: fix a warning in TcpSslConn.cpp that prevents successful compilation on gcc 8.3 (#51

Errored: apache/geode-examples#366 (rel/v1.10.0 - 075158b)

Build Update for apache/geode-examples - Build: #366 Status: Errored Duration: 53 secs Commit: 075158b (rel/v1.10.0) Author: Dick Cavender Message: temporarily point to staging repo for CI purposes View the changeset: https://github.com/apache/geode-examples/c

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

I don't know enough about the limitations between the two libraries. BUT I would prefer, like Kirk, some consistency w.r.t. implementations. Also, this is for testing, so I'm really questioning are we going to be pushing the boundaries of what this library can do. In addition, if there would b

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

I would prefer we stick to one family of libraries for JSON. So, if there's a comparable release from Jackson, then I think we should go with that instead. On Wed, Sep 25, 2019 at 12:55 PM Owen Nichols wrote: > The Jackson-jq project actually imports the full testsuite from the “real" > jq proje

[VOTE] Apache Geode 1.10.0.RC2

It's past the announced deadline and we have enough votes to close the voting. Voting status == +1: 7 binding votes, 2 non-binding votes * Dave Barnes (PMC member) * Anthony Baker (PMC Member) * Jinmei Liao (PMC member) * Jacob Barrett (PMC member) * Dan Smith (PMC member) * Udo Kohlmeyer

Re: Spring Boot with Geode 1.10

That was the problem ... I had an old reference to Spring Boot v2.0.1. Updated it to 2.1.9 and now the micrometer versions line up. But I appreciate your broader point: even that version of Spring Boot is only intended to work with Geode 1.9, so trying to mix-and-match with 1.10 is ill-advised

Re: Spring Boot with Geode 1.10

Additionally, I would encourage others to read... https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-maven-plugin And, when using Gradle (instead)... https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-gradle-plugin This

Re: Spring Boot with Geode 1.10

There is no version of Spring Boot (SBDG) currently built on Apache Geode 1.10 at the moment. In general, you should understand 2 things. 1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent on is indirectly (transitively) determined by upstream dependencies. SBDG -> Sprin

Re: Spring Boot with Geode 1.10

Offline discovery… Looking at ./gradlew dependencies shows that micrometer is being downgraded by spring dependency plugin to 1.0.3. Attempting different versions of spring boot. -Jake > On Sep 25, 2019, at 1:04 PM, Owen Nichols wrote: > > This still pulls in micrometer 1.0.3 > > dependenc

Re: Spring Boot with Geode 1.10

This still pulls in micrometer 1.0.3 dependencies { compile('org.springframework.boot:spring-boot-starter') implementation(platform('org.apache.geode:geode-client-bom:1.10.0')) implementation('org.apache.geode:geode-core') implementation('org.apache.geode:geode-cq') testCompile('org.

Re: [DISCUSS] GEODE-7241 - make Jar not War?

@Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar. I never heard of them until now. Gotta love the 80s Rock/Heavy Metal Era. On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett wrote: > Udo, > > I didn’t say we shouldn’t fix it for the future. I said I don’t believe it > warrants a backpo

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

The Jackson-jq project actually imports the full testsuite from the “real" jq project, and asks that any discrepancy be reported as a bug. They list the known differences in great detail…so unless you are using $__loc__ or date arithmetic or

Spring Boot with Geode 1.10

Changing subject… Try dependencies { implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’)) implementation(‘org.apache.geode:geode-core’) implementation('org.apache.geode:geode-cq’) } Does that make a difference? > On Sep 25, 2019, at 12:35 PM, Owen Nichol

Re: [VOTE] Apache Geode 1.10.0.RC2

My build.gradle is pretty simple: repositories { mavenCentral() maven { url 'https://repository.apache.org/content/repositories/orgapachegeode-1059' } } dependencies { compile('org.springframework.boot:spring-boot-starter') compile 'org.apache.geode:geode-core:1.10.0' compile 'org

Re: [VOTE] Apache Geode 1.10.0.RC2

> On Sep 25, 2019, at 12:26 PM, Owen Nichols wrote: > > ⚠️ to run my spring boot client for above test, I had to manually add compile > 'io.micrometer:micrometer-core:1.2.0' , otherwise local region creation blows > up with “java.lang.NoSuchMethodError” due to spring-boot-starter pulling in

Re: [VOTE] Apache Geode 1.10.0.RC2

+0 ✅ verified that apache-geode-native-1.10.0-src.tar.gz extracts with a versioned top-level directory ✅ set up a small cluster (2 locators, 3 servers, 1 client, ssl enabled) and ran some simple puts, gets, and CQ. ⚠️ I cannot give “+1" yet because the release notes

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Udo, I didn’t say we shouldn’t fix it for the future. I said I don’t believe it warrants a backport and a patch release. -Jake

Re: [DISCUSS] GEODE-7241 - make Jar not War?

@Jake, whilst I agree with your statement that there is a preference that sers use GFSH to manage their clusters. With that statement are you also making a blanket statement we should remove the exposed public API's we expose in GEODE to start a Client/Server/Locator? IF the expected usage of

Re: [DISCUSS] GEODE-7241 - make Jar not War?

-1 for updating previous releases or merging into the current release. I see no overwhelming need to have these published so that a downstream project can subvert the prescribed why of starting a server with all its dependencies. A workaround to this issue is to depend on the full distribution t

Re: [DISCUSS] GEODE-7241 - make Jar not War?

@Anthony, you must have missed the LACK OF excitement in that question... 1.8.x should stay as is... I was merely asking the question. --Udo On 9/25/19 11:58 AM, Anthony Baker wrote: Since SBDG is fixed to Geode 1.9.x I can see an argument for backporting to there. I’m personally not as exci

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Since SBDG is fixed to Geode 1.9.x I can see an argument for backporting to there. I’m personally not as excited about a new 1.8 patch release but I’m open to hearing your ideas :-) Anthony > On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer wrote: > > So it seems there is consensus around jar vs

Re: [DISCUSS] - Cutting of release 1.9.2

It seems there is consensus to cut a 1.9.2 release to include GEODE-7121. --Udo On 9/20/19 3:34 PM, Jens Deppe wrote: +1 for creating a 1.9.2 release with this fix. On Fri, Sep 20, 2019 at 2:00 PM Udo Kohlmeyer wrote: John, thank you! You are correct, not sure what I was thinking.. Geode 1

Re: [DISCUSS] GEODE-7241 - make Jar not War?

So it seems there is consensus around jar vs war. WAR's win by nose. (until we can find a more creative way to expose said artifacts) That said, do we need to start another thread about fixing 1.8.x or 1.9.x? I'm already considering proposing that GEODE-7241 is included into 1.9.2, as that pat

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

I did look at jackson-jq before I considered java-jq, but it is a re-implementation of jq and this statement on that site puts me off: "jackson-jq aims to be a compatible jq implementation. However, not all the features are available; some features are not relevant as being a java library and some

Re: [DISCUSS] GEODE-7241 - make Jar not War?

> On Sep 25, 2019, at 11:01 AM, John Blum wrote: > -1 to publishing a GWAR file. These are still valid WAR files regardless > of the dependencies they provide or don't provide (which is a documentation > concern in my mind). Just to be really clear, GWAR was a joke and a reference to the popul

Re: [DISCUSS] GEODE-7241 - make Jar not War?

It occurred to me after *Charlie* shared the link to installing *Pulse* in a standalone Servlet Container (e.g. Apache Tomcat) that we don't properly describe how to handle the Geode dependencies (e.g. geode-core). Again, this is not bundled as part of the Geode WAR files. -1 to publishing a GWAR

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Thanks for the reminder. If these files are required to start a geode member, I agree they should be published artifacts. Perhaps there’s a better way to pull them in…but this seems like the best option for now. Anthony > On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer wrote: > > @Anthony. Tic

Re: [DISCUSS] GEODE-7241 - make Jar not War?

@Anthony. Ticket was updated.. In a nutshell, to run integration tests, using the REST endpoints, requires the starting of the server with and embedded web-server. As all tests run on dependency management only and don't have access to a downloaded product, the HTTP endpoints are not part of t

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

For a pure-java implementation, might be worth considering https://github.com/eiiches/jackson-jq > On Sep 25, 2019, at 9:40 AM, Dan Smith wrote: > > +1 - sounds good. > > BTW - We've previously found libraries that use JNA tend to be more > flaky/platform dependent than pure java libaries - fo

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Just incase here is the docs on pushing the war: https://geode.apache.org/docs/guide/16/tools_modules/pulse/pulse-hosted.html On Wed, Sep 25, 2019 at 9:53 AM Jacob Barrett wrote: > > > > On Sep 25, 2019, at 9:33 AM, Dan Smith wrote: > > > > +1 to making them .GWAR instead :) > > Ok I think this

Re: [DISCUSS] GEODE-7241 - make Jar not War?

> On Sep 25, 2019, at 9:33 AM, Dan Smith wrote: > > +1 to making them .GWAR instead :) Ok I think this constitutes consensus on GWAR! ;)

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

+1 - sounds good. BTW - We've previously found libraries that use JNA tend to be more flaky/platform dependent than pure java libaries - for example we ripped out a snappy native wrapper in favor of a pure java implementation. -Dan On Wed, Sep 25, 2019 at 8:39 AM Anthony Baker wrote: > Sounds

Re: [DISCUSS] GEODE-7241 - make Jar not War?

+1 to Jens and John comments. I'm 100% sure some of our users certainly deploy the *war* file (at least the *PULSE* one) to external web application servers. Cheers. On Wed, Sep 25, 2019 at 5:07 PM Jens Deppe wrote: > I also cannot recall any reason as to the need to *publish* wars. > > However,

Re: [DISCUSS] GEODE-7241 - make Jar not War?

I could see value in publishing the war files, if geode will actually pick up the war file from the classpath and deploy it when these features are enabled. Udo - it looks like you actually made a change with GEODE-5660 to enable that? +1 to making them .GWAR instead :) -Dan On Wed, Sep 25, 2019

Re: [DISCUSS] GEODE-7241 - make Jar not War?

I also cannot recall any reason as to the need to *publish* wars. However, please do not change the files to .jar. To John's point, despite the lack of some dependent jars, the structure still conforms to a .war format. --Jens On Wed, Sep 25, 2019 at 8:40 AM John Blum wrote: > Actually, to cla

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

Sounds good, thanks for the heads up. Anthony > On Sep 25, 2019, at 8:37 AM, Jinmei Liao wrote: > > Management rest api wants to add some default jq selector to the swagger > api docs so that the downstream client tool can use it as a starting point > to filter/format the json response to a mo

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Actually, to clarify 2 points. 1. Technically, it is a bit more involved than simply just validating the "format". For instance, the web.xml file must be valid and well-formed. 2. There was a reason why the geode-core and other Apache Geode libs were not bundled in WEB-INF/lib of the WAR files, s

[PROPOSAL] adding java-jq to GEODE dependency for testing

Management rest api wants to add some default jq selector to the swagger api docs so that the downstream client tool can use it as a starting point to filter/format the json response to a more readable form. In order to test these jq selectors, we would like to use a java library described here: ht

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Udo, Can you update GEODE-7241 to help us understand the reason why we need to publish geode-web* WARs to maven? I get that we used to do this but I can’t recall why we choose that approach. There is one request for Pulse on maven (GEODE-6208). Anthony > On Sep 24, 2019, at 3:44 PM, Udo Ko

Re: New geode-log4j module

Great writeup, thanks for sharing Kirk! Anthony > On Sep 24, 2019, at 10:24 AM, Kirk Lund wrote: > > All classes that use *log4j-core* have now moved to the new module > *geode-log4j > *on develop. The default log4j2.xml configuration file for Geode Locators > and Servers has also moved to ge

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Bundling "all" dependencies in a WAR file is a rather subjective topic since, typically, in practice developers did not bundle things like JDBC drivers in a WAR file for their Web app. Common practice was to put "shared" libs in the Servlet Containers global libs directory (using the Common ClassL

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Seems these should have been Jars all along... On 9/24/19 8:09 PM, Jacob Barrett wrote: Why publish them as WAR files at all? As they are currently packaged they can't be deployed in just any J2EE web container because they lack all the dependencies. Sure they look like WAR files internally bu