Most of these will seem obvious. If they aren’t, you’re welcome.
No property files in EARs or WARs
Placing property files in a deployment package defeats the purpose of being able to update configuration values without a deployment.
Also be sure that your code supports immediate updates through property files using mechanisms such as a cache that checks for last update or a re-load mechanism that can be fired by the property file change.
Use Naming Conventions
When creating new projects and packages, either follow existing naming conventions/patterns or raise the need for a change and refactor all of them.
Always Use Relative Paths
Should not require a mention as we all know it, but seems folks forget it frequently so this is a reminder.
Always Document
Projects must have a readme that explains how to use the project.
Scripts should have usage notes at the top of the script. Preferably, the script should also do parameter validation and print out usage notes on validation failure.
All Connections Need Timeout Set
If all calls can be managed to a singlet timeout value, set it using an application-server level configuration. If not, manage it on a per connection basis with a single property file external of the deployment archive (usually the EAR or WAR) containing the timeouts to allow for updates to timeouts without compilation.
© Scott S. Nelson