Reviewed and merged. Thanks for all your hard work on this one!
-Dan
On Mon, Sep 23, 2019 at 6:18 AM Alberto Gomez
wrote:
> Hi,
>
> Could I please get some extra reviewers for
> https://github.com/apache/geode/pull/3888?
>
> This PR is about GEODE-7049: Add timeout parameter to Java client
> Ex
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 geode-log4j.
The first Geode release expected to include this change is 1.11.0.
The geode-log4j module is include
+1
Ran geode-release-check (checks signatures, source build, simple gfsh test)
-Dan
On Mon, Sep 23, 2019 at 3:20 PM Jacob Barrett wrote:
> +1
>
> Still think it is ok to ship but found another annoying issue. When
> running Geode Native C++ integration tests (new framework) an indented
> disab
+1
- Built from source and ran unit tests
- Used GFSH to create a locator and server and do some puts/gets
- Checked version in GFSH
- Built and ran all of the examples
- Verified SHAs and signatures
The luceneSpatial project in geode-examples fails for me when running...
>
To add
Hi there Geode Dev,
I've just run into an interesting situation where I've realized that
since Geode 1.8.0, the maven repository artifacts for geode-web and
geode-web-api have changed from type war to jars.
Is this something that was intentional?
--Udo
Huh. Looks like we're missing a 'from components.web' in publish.gradle if
we want to publish the war files. I'm not sure why this has changed.
I'm not sure how we want to actually ship these projects - they are in the
.tgz of geode. They are not really standalone war files, from what I
remember -
ConnectCommandAcceptanceTest is now failing on develop. Looks like the test
is using Geode 1.3.0 (not sure why).
It also looks like my commit and the following commit didn't merge properly
despite not having any conflicts. Looking into how to fix it now.
It's possible that GEODE-7168 removed geod
Dan, thank you for the investigation.
The war artifacts have been published to maven, since the dawn of time.
Whilst I agree that they are not stand-alone, there is the ability to
reference them via maven/gradle as dependencies and start a server using
Geode API's or other technologies like Sp
Given that 1.8, 1.9 are currently publishing the jar's to the maven
central, instead of wars, I can only assume that 1.10 would do the same.
Also, given that everyone is surprised by this, means that we have not
address this issue.
Until we can confirm that we would publish war files instead
It's not a problem in TomcatInstall. Nothing obvious anywhere. Even the
output that GfshRule says is missing the string actually does contain the
missing text. I have no idea why this passed in precheckin but fails now...
On Tue, Sep 24, 2019 at 11:16 AM Kirk Lund wrote:
> ConnectCommandAcceptan
It's a race condition in how GfshRule, GfshExecution, and ProcessLogger
fork a process before attaching the stdout and stderr listeners. The
changes for geode-log4j caused this race condition window to take slightly
longer. I'll have a fix soon and ConnectCommandAcceptanceTest should then
be back t
Udo, is there a Jira about this issue?
Since this is not a new issue in 1.10 (as you say, it is the case in 1.8,
1.9, 1.9.1) is it really a -1 ?
On Tue, Sep 24, 2019 at 12:01 PM Udo Kohlmeyer wrote:
> Given that 1.8, 1.9 are currently publishing the jar's to the maven
> central, instead of wars,
Please review https://github.com/apache/geode/pull/4089 for the fix.
Thanks,
Kirk
On Tue, Sep 24, 2019 at 1:17 PM Kirk Lund wrote:
> It's a race condition in how GfshRule, GfshExecution, and ProcessLogger
> fork a process before attaching the stdout and stderr listeners. The
> changes for geode
Hi there Robert,
Whilst it is not a new issue (for 1.10), but missing something this
critical is an automatic -1, in my books. It has been a problem since
1.8 and we've just missed it, otherwise 1.8 onwards should have been
rejected.
There is not a JIRA, as I have not yet received a positive
I'm going to change my vote to "+1".
This is an issue that needs to be resolved. I would have preferred 1.10,
but maybe it is good enough to have it fixed in 1.11.
@Robert, https://issues.apache.org/jira/browse/GEODE-7241 is the JIRA
you were looking for.
We definitely have to fix this issu
I am working on the change to get the geode-web and geode-web-api war
artifacts published instead of the jars. I have found the
geode-web-management project is also producing a war artifact, in addition
to a jar. Do we want it to be published as well? What is the criterion we
use to decide?
I thin
The geode-pulse module also builds a war, but does not publish it. Is this
an oversight, or by design?
On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton
wrote:
> I am working on the change to get the geode-web and geode-web-api war
> artifacts published instead of the jars. I have found the
> geod
Maybe the better question is, WHY are we publishing geode-web and
geode-web-api.
Pulse, from what I remember, could be a standalone deployment. At least
that is what I remember.
Most likely an oversight...
--Udo
On 9/24/19 3:38 PM, Robert Houghton wrote:
The geode-pulse module also builds
For context, these are the docs for running Pulse as stand alone
https://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_795C97B46B9843528961A094EE520782
The instructions always seemed odd since we tell folks to go "tools/pulse"
to copy the pulse.war file to their dedicate
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 but they are really
modules that expect to run in and only in the Geode server. Publishing t
20 matches
Mail list logo
