Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

RebelRant: Don’t create a new JSR just because you can

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 or something similar. I have my doubts on how to standardize that in a single JSR and even if it should be standardized.

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 add/removePropertyChangeListener and 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.

Let me know what you think in the comments section below, or on Twitter @redlabbe or @ZeroTurnaround!

  • This post is rather old at this point, but I disagree with the statement that there is no need for a configuration JSR. However, when I think of ‘configuration’ I think of it less in the sense of the SaaS world where we change database settings or service endpoints when moving from Dev->Test->QA->Production, and more end-user configuration of packaged applications.

    In an ideal world, I would imagine applications would be able to provide a list of settings that can be customized by an administrator, these could be displayed in a property editor in your application containers administration interface and allow set up of the application in a standard way.

    Having separate profiles for different environments is a non-issue, if that’s all you care about then yes, that’s a tools issue, you can easily have chef deploy an unpacked war and replace a properties file, but that’s not the experience I want system administrators deploying my application to have.