Closed huntc closed 7 years ago
@huntc can you elaborate on the use case?
If I plan to deploy a lagom service in ConductR, then I'll mix in ConductRApplicationComponents
(when in scala) or let ConductR provide ServiceLocatorModule
(when in java).
If I plan on using some other deployment strategy then I have to work out what pieces of the cake to take. I'll review lagom docs and work it out. Why fallback to a ConfigurationServiceLocator
(static config)?
@ignasi35 conductr-lib is designed so that if called when your process is invoked outside of ConductR e.g. when testing from the command line, then its calls are benign. From a build perspective, we want to be able to declare that ConductR is the cluster management target, but still be able to run it without being invoked from ConductR.
A case in point is the lagom chirper sample that we've recently converted to Maven. We're now going further and seeing that Maven build produce a Docker image. We'd like to be able to run the Docker image via docker run myimage
, without ConductR being involved. This is a common pattern for a developer that is familiar with Docker. However, when having been invoked by ConductR, we want ConductR's service locator to kick in. Make sense?
Makes sense, thanks @huntc
Prior to this commit there was no fallback URI for Lagom service locator lookups. The use-case for supporting the running of a Lagom service outside of ConductR, and outside of Lagom's development mode, was unsupported. This is an important use-case e.g. when running a Lagom service within Docker outside of ConductR.
This commit re-introduces the prod mode check that https://github.com/typesafehub/conductr-lib/pull/100 unwound, and additionally uses Lagom's configuration based service locator where ConductR hasn't invoked the bundle.