Just a quickie Guard release to make it more flexible when embedded in applications. You can now pull the config from an explicit path or environment variable. You can download from GitHub or Sourceforge.
- Updated src/main/java/org/guanxi/sp/guard/GuardBase.java. Can now specify config file location using environment variable or explicit path. Defaults to /WEB-INF/guanxi_sp_guard/config/guanxi-sp-guard.properties
- Updated src/main/webapp/WEB-INF/web.xml. Added optional configFile init-param to Guanxi Resource Guard
When your system is out in the wild, more often than not logging is the only way you can tell what’s going on if things go a bit wonky. Logging is your app’s way of saying something went wrong and why. Although I use the word “why”, the semantics aren’t that simple but the logs are the first stop in tracing the lineage of a fault. So it’s important to get it right and after seeing many logging patterns, both good and bad, my thoughts on the subject might be of some help to folk new to application logging.
The first question to ask yourself is, who’s doing the logging? Is it the caller or the callee? A common problem I see is what I’ll call Dispersed Logging. This is where the caller and the callee each have their own log files and tracking down a problem involves analysing both files and trying to sync dates and times, especially if the calling is done over JMS.