How I like my Java | Javalobby

How I like my Java | Javalobby

• these deployment strategies will help your ops and dev teams build more managable services
The first step is to have the native operating system packages as build artifacts rolling out of your continuous integration server - No .ear, .war or .jar files: I want to have rpms or debs. With things like fpm or the maven rpm plugin this should not be an extra hassle, and the advantages you get from doing this are priceless.
• Most native package systems support 
• dependency resolution,
• file verification, and 
• upgrades (or downgrades). 
• These are things you would have to implement yourself or cobble together from multiple tools. 
• As a bonus, your fellow sysadmins are likely already comfortable with the native package tool used on your systems.
• PROXIED, NOT RUNNING AS ROOT
• after launching the service, the wrapper can return back with a successful exit code while your service is not ready yet. The application server might be ready, but your applications themselves are still starting up. If you are monitoring these applications (e.g for High Availability), you really only want to treat them as 'active' when the application is ready, so you don't want your wrapper script to return, "OK," before the application has been deployed and ready. Otherwise, you end up with false positives or nodes that failover before the application has ever started. It's pretty easy to create a ping-pong service flapping scenario on a cluster this way.
A good approach is to create a standard location for all your applications, like /etc/$vendor/app/, where you place the appropriate configuration files. 
• Volatile application configuration must be outside the artifact that comes out the build (.ear , .jar, .war, .rpm). The content of these files should be managed by a configuration management tool such as puppet, chef, or cfengine. The developers should be given a basic training so they can provide the systems team with the appropriate configuration templates.
• it is usually insufficient to simply check if a tcp server is listening. A nice solution is to have a simple plain text page with a list of critical services and whether they are OK or not (true/false)
• This benefits humans as well as machines. Tools like mon, heartbeat or loadbalancers can just grep for "false" in the file.
• This kind of approach could also be used to provide you with metrics you can't learn from the JVM, such as number of concurrent users or other valid application metadata for measurement and trending purposes.