Come again, a ‘DevOps’ JSR you say?
While standardization usually is a good thing, the so-called ‘DevOps’ JSR does produce some doubt in my mind. In my humble opinion, the scope of the Java-Config JSR as described is out of scope for a JSR. The use cases being described there are more for a tool, and perhaps they should consider writing an application setup specification (ASS) instead of a JSR.
While I totally agree with the statement “We have to get rid with the paradigm to ‘package your config within your WAR’ that breaks flexibility to embrace various environments”, usually there is only a single WAR package that can be deployed anywhere given a system property
the.package.of.app.configLocation or something similar. I have my doubts on how to standardize that in a single JSR and even if it should be standardized.
— Jevgeni Kabanov (@ekabanov) October 23, 2013
When we start suggesting that “External configuration files should be located here, and named like this” that’s like saying ‘thou shalt always put your knife in your right hand and your fork in the left’ (and what if you’re eating with a spoon and a knife? and your neighbour with a spoon and a fork…)
What’s next? Will engineers start making suggestions for JSRs that define which level of environments we have to use, or from where and how my application has to load its internal configurational parameters, who’s allowed to deploy?
Java can do this without a JSR
If you think about it, Java already has plenty of options to achieve all these things. We have Properties, Caching, JMX, OSGI, Modularity and some more, all can help your internal application configuration varying from application settings to changing implementations of contracts at runtime or for deployment on specific environments.
All these things situate themselves closely to the application, if not in the application itself (i.e. as standalone or something deployed on a app server or web server). Wouldn’t it be better to extend existing JSR’s to support parts of what the java-config-guys are proposing?
I don’t think that the deployment and management of an app is the responsibility of Java as defined in a JSR. It is more something that is done by tools and such and thus usually an external something (like puppet or chef).
While the Java ecosystem can provide us with tools and utilities to achieve configuration management, it should not enforce us how to build and deploy the same application to various environments. One useful thing that could come out of a java-config JSR is an extension of Properties: I’m looking at Spring’s property loading support with
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer, which offers a standardized way to load/override properties inside the application.
Combine that power with something like the withdrawn JSR-295 for live reloading properties into beans or with
PropertyChangeEvent + PropertyChangeListener from
java.beans. (Which is just bit cumbersome to use and lots of code to write if you want to use it frequently, so could be made easier with for example Annotations?). And Java could be well on it’s way to provide an easy way for external tools to provide multiple settings depending on different environments and allow to load/reload them. Yes for that last part we could use a JSR, the ‘properties improved’ JSR!
But please let us free to choose the naming of our environments. Don’t enforce names like dev, test, staging, production because the JSR panel uses those. I like to call mine Fubar, Black Hole, Almost There and Shiny Star.