More accurately, I think geode-core is only required when TLS is enabled on the locator and Pulse needs to make JMX/RMI calls over TLS.
I would vote for option 2 in this scenario. --Jens On Tue, Apr 30, 2019 at 1:44 PM Jinmei Liao <jil...@pivotal.io> wrote: > 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 <mole...@pivotal.io> > wrote: > > > Hi Geode Community! > > > > Some colleagues and I were looking at GEODE-6683 ( > > https://issues.apache.org/jira/browse/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 ( > > > > > https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html > > ) > > 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 > > > > > -- > Cheers > > Jinmei >
