chadjnsn
commented
8 years ago Something like this could probably address that 'Add support for command based Health Check handlers' entry on the roadmap (you just make a simple class that handles the logic, compile it into a jar, and drop it in a directory). It's also basically using the same approach suggested in Issue #4 (albeit for healthchecks, instead of request handlers) except it just uses the Service Loader directly instead of going through Governator (although it wouldn't take much to convert it to use governator instead).
aspyker
Within Nike, we've been using Prana for a number of internal systems, but we needed a way to run it alongside applications other than web apps, and as such we needed a way to let Prana determine the health of those applications. To do this, we basically replaced the existing HealthCheck implementation with a plugin-based system that includes a default implementation to ensure it is still backwards compatible.
To do this, we pulled out most of the logic from the HealthCheckHandler and now the handler calls into a HealthCheckService. That service uses a ServiceLoader to look through a specific directory (configured via an archaius property) for .jar files that contain an implementation of a new HealthCheck interface. It then bootstraps those implementations and attempts to use them to determine the health of whatever app Prana is paired with. If there are no external implementations found, then the service defaults to using a DefaultHealthCheck which is the same one that Prana used before. This logic is only run the first time the HealthCheck endpoint is hit, and because of the default implementation, it should be completely backwards compatible.
Within Nike we've been using this implementation, and thought it might be a good candidate for Prana. If this is something you guys are interested in, I can also provide you with some documentation that explains pretty clearly how to make a new healthcheck implementation and use it.