Java EE Configuration JSR Deferred

Configuration was one of the more popular items on the Java EE 8 survey. While the exact features that would be included in a configuration JSR for Java EE remains relatively vague, I think we were all looking forward to a possible JSR largely spearheaded by Anatole Tresch of Credit Suisse. The idea was that such a JSR would provide a cohesive solution for configuring Java EE applications and would receive a level of support from Oracle, including possibly sharing responsibility for leading the specification. Unfortunately the configuration JSR effort has currently been deferred for unforeseen but unavoidable circumstances principally related to long-term resourcing commitments especially for developing and maintaining the associated reference implementation (RI) as well as the compatibility test kit (TCK).

This is truly unfortunate as this would have been a shining example of a non-Java EE vendor (in this case Credit Suisse) contributing a significant part of the Java EE platform. It is still important to applaud Anatole Tresch for his initiative, passion, dedication and courage. Similarly the community should be grateful to Credit Suisse for seriously considering such a significant investment to help move the Java EE platform and community forward. As all of us in IT know, making tough calls on resourcing is never easy and it is far better to make difficult decisions early rather than at later stages of an effort. Anatole is still moving forward with his JavaOne 2014 talk on the configuration JSR effort. The talk is a great opportunity to share ideas and solidify underlying use cases through community feedback. This thought provoking post alludes to some of the complex uncertainties that this JSR would need to carefully explore.

While a cohesive configuration JSR effort must be deferred at least for now, there is no reason to dismay too much. Some of the more well-understood problems that such as JSR would have solved could still be considered as part of the Java EE 8 platform JSR. A separate JSR would have likely required a high degree of collaboration at the platform level anyway. Another possibility is to have core APIs like CDI consider what needs to be done to make configuration easier in Java EE. Lastly, it's worth keeping in mind that some of the problems that such as JSR would have addressed may already be solvable using mechanisms included in Java EE or with tools that are commonly used in Java EE development such as:

  • Using the <alt-dd> tag that has been included in Java EE for a while.
  • CDI @Alternative.
  • JSF project stages.
  • The configuration centric features included in DeltaSpike Core. The mature Apache Commons Configuration project has had similar capabilities for a while, albeit more focused on look-up (rather than injection) and Java SE (rather than Java EE).
  • The rich set of configuration and conditional build focused Maven features such as profiles and replacers (this really isn't anything specific to Maven, most emerging or mainstream build systems have such capabilities for good reasons).

In my own personal experience as a consultant I have found the Maven features in particular a sufficient, easy-to-use and elegant solution for the vast majority of Java EE projects. That being said the distinction for the configuration JSR might have been that while Maven is a build-time solution, there is perhaps a need to solve configuration issues at deployment-time or at run-time. One should note though that while dependent upon non-standard tooling many modern application servers do support changing JNDI bindings at runtime.

What do you think? As always, don't hesitate to sound off here.

Please note that any views expressed here are my own only and certainly does not reflect the position of Oracle as a company.

Comments:

In my opinion, the (runtime-)configurability of a JEE application is totally achieved via administered objects that are bound into the JNDI-Context and injected with @Resource.

But there is still a need in support by the application-servers to set/specify the values of these administered objects. There could be more (property-inspector-like) editor support.

Yet in remind, that every change to an administered object requires a restart of your application, this solution fits in most cases.

For all the other cases the question is: How often do you (re)configure your application? Do you really need runtime-configuration?

If yes, then the better solution would be a simple CDI-extension (Deltaspike etc.) paired with a ReST interface to set/specify configuration values.

So, as a clue: for me, there is no need to standardize configurations as all usecases can be managed with the existing standards ootb. :-)

Robert

Posted by guest on September 17, 2014 at 12:30 AM PDT #

Great points and thanks for reminding me. I've now updated the post accordingly.

Posted by Reza Rahman on September 17, 2014 at 08:22 AM PDT #

Externalizing a MDB activation spec...can b a simple use case where we need configuration JSR. ..so that all application vendors support it.

Posted by vishy on October 01, 2014 at 04:26 PM PDT #

Post a Comment:
Comments are closed for this entry.