So I've spent rather longer than I wanted to on this, and still haven't come up with a good answer.
Here's the problem.
For whatever reason we want to standardize the way we deal with GemFire. That means (for us) everything in a JVM we control. We're a spring-java shop - or for purposes of this discussion at least we are - which means spring configured standalone JVMs. This is a client-server setup with everyone going through Locators to find and control the regions as required.
Everything is peachy apart from the Locators.
I know, I know, the manual says use GFSH but we would prefer not to. Standardize and all that.
Here's my problem. There are two ways I know of to fire up a locator. Neither (sadly) are in spring-data so I'm back to actually doing some work.
#1 is to use the LocatorLauncher class.
This is fairly simple. I fire up a builder, shove in a few parameters and do a start() followed by a waitOnLocator().
The problem is that I can't see a way to create (or if it is creating, connect to) a DS. So Pulse isn't working and I can't pass in the list of my other Locators.
This means Pulse doesn't work as well as I'd have liked.
#2 is to use the Locator class itself (with startLocatorAndDS).
This was a little more fiddly - mainly because the DS requires the parameters to be duplicated in some places and the documentation is light on detail here.
More trial and error than I'd have liked was needed, but c'est la vie. It now all works just fine. Pulse is good, my cache-servers are happy, my clients work and (mostly) this is all good.
The problem here is that once it has kicked off the Locator, I have to manage the process (and I'm using a Thread.sleep, which doesn't thrill me at all) to stop the application exiting.
This seems wrong somehow - I'd dearly like to have a method on the Locator that allows me to wait until it has finished, similar to #1, but can't find one.
So apart from some whining about configuration, I'm wondering if I missed something - either a way to start/join a DS in #1 or a suspend method in #2.
Or a hint that this is totally the wrong way to go about it and a pointer to a "better" approach.