geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinmei Liao <>
Subject Re: Pulse - Non-Embedded Mode
Date Tue, 30 Apr 2019 20:44:13 GMT
I believe to run pulse in non-embedded mode, you just need to install the
war in a web server and some configuration changes, you don't need
geode-core at all.

We do lack the acceptance test to run pulse in non-embedded mode though. We
have a few unit tests that touches some aspect of it.

On Tue, Apr 30, 2019 at 12:10 PM Michael Oleske <> wrote:

> Hi Geode Community!
> Some colleagues and I were looking at GEODE-6683 (
> and noticed that we do
> not have test coverage for running Pulse in non-embedded mode.  We were
> wondering what our strategy is around Pulse in non-embedded mode. In order
> to fully fix the issue, we would prefer to have a high-level acceptance
> test that actually tries to run Pule in non-embedded mode (we could not
> find an existing acceptance test that performs this).   However, this
> non-embedded mode seems a bit odd, as the instructions for it (
> )
> are slightly confusing and need some updating for geode (such as making
> sure geode-core is on the class path). It seems strange to try and host a
> web app in this way, especially with the extra configuration needed (cannot
> just plop the Pulse war file in my web server with some config and have it
> work).  So there's some questions about the best path forward.
> 1.  Should we continue supporting non-embedded mode for Pulse?  It seems
> like it may be useful to allow Pulse to run outside of a member, but not as
> it currently does.  If it was deprecated, I wouldn't be as insistent on an
> acceptance test for it.
> 2.  Should we try to make a separate artifact that is intended to be
> deployed on a web server?  This would have a new artifact that could run
> elsewhere then (with maybe a user provided config file for properties.)
> 3.  For the issue that brought up these questions (GEODE-6683), we have
> currently only written some unit tests to add the properties. So the
> current question is what type of path forward should we take?
> -michael



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message