So long as we **never** remove the ability to start an "embedded" *Locator/Manager* in an [application] *CacheServer *process*, *which is highly valuable during "*development*".
For instance, I may want to spin up an application peer *CacheServer* instance with an embedded *Locator/Manager*, like this... https://github.com/jxblum/simplifying-apache-geode-with-spring-data/blob/master/simplifying-apachegeode-springdata-complete/src/main/java/example/app/server/SpringBootApacheGeodeServerApplication.java Given this simple *Spring Boot *application class, it is real easy to form a "*cluster of servers*" also just by changing the run profile configuration in my IDE. Optionally, I should not have to start a *Manager* in my application-based *CacheServer* even if I do start an embedded *Locator*. Additionally, while it might be less likely to occur, it is also nice to be able to start an application-based *CacheServer* process with an embedded *Manager* without having to start a *Locator* if I don't want to, since it is still possible to connect to this node using *Gfsh*, like so... gfsh> connect --jmx-manager=localhost[1099] However, the real point is, as an application developer, I should not have to go outside my IDE and use *Gfsh* to spin up separate *Locator/Manager(s)* and *CacheServer*(s), which is a non-starter for quick, iterative development, particularly if I want to enable *debugging*, which is significantly more difficult to do with *Gfsh* (not impossible, but definitely more difficult). *Gfsh* is not a "development" tool. -j
