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
