Tag Archives: jcp

Configuration JSR in Java EE 8 – What should be covered ?

javaee, ,

GeeCON 2014 was very inspiring! A really greet feeling from the Polish Java community, awesome bunch of organizers (Andrej (@ags313), Adam (@maneo), Konrad (ktosopl), Adrian (@adrno), rest of the gang is just super nice), great technical content, courteous and helpful volunteers, lots of socializing space/opportunities, and most importantly fun! This was my second GeeCON and would love to go back there next year.

During speakers’ dinner, Anatole (@atsticks) and I were talking about the Configuration JSR (scheduled to be part of Java EE 8) and he shared the proposal. Instead of reading the proposal, I decided to put my thoughts down first so as not to be tainted by it. So this blog describe the use cases that I think this JSR should address. This by no means is a comprehensive list, or in any particular priority order. It is solely intended as input to the JSR and Expert Group based upon Anatole’s request, Laird Nelson (@chuggid) is the other spec lead on this.

Here goes the list …

  1. Application-wide configuration may be provided using XML-based configuration (application.xml ?), Annotations, and a programmatic Java API. A graphical web-based tool may simplify generation of these artifacts as well.
  2. One of the primary concerns during devops is the ability to take the same WAR file from development, to testing, and finally to production. Unzipping the archive and bundling a different deployment descriptor to point to different databases/servers is used as a workaround, but not recommended. If configuration is specified using a XML configuration file, then there should be the ability to specify configuration for all of these stages. Each stage could point to a different JMS destination, JNDI reference for data source, port numbers, etc.For example:
    In addition, a mechanism to trigger a particular stage would need to be defined. An external configuration tool that can trigger a particular environment may be one way to achieve this. Relying upon environment variables does is not a good idea.

    Custom stages should be permitted as this would allow to target different environments for stress, performance, regression, integration, and different sorts of testing.

    All of this, of course, would work for Java EE components only.

  3. Configuration may not be restricted to only Java EE components. It may include the max amount of memory that the application could use on the server, whether high availability is enabled or not, min/max number of servers in a cluster, etc. This would require to specify the configuration outside of Java EE context.
  4. Stages may inherit from other stages. This would allow a production environment to point to the test database rather easily. In this case, inheritance rules would need to be defined.
  5. Application configuration may be specified exclusively outside the application. This could be done using the graphical tool, and stored in a persistent store. This would allow a system administrator to easily pick a particular configuration.
  6. Reasonable defaults should be defined for the entire application, such as more logging/debugging during development stage. This will allow containers to spit out more detailed and useful information during different stages. For example, JSF displays an error message on XHTML page, even if there is no place holder for it, during development phase but hides it during the production stage.
  7. A mechanism to store all the configuration information in a variety of persistent stores would be useful. One of the common ways could be “application.xml” as a file, typically bundled in the archive itself. Storing this information in a relational database could be useful as well. This would allow developers to focus on application configuration during development, possibly using annotations or “application.xml”. And then retrieve a testing/production configuration from a database when targeting those stages.
  8. An archive would typically have a “persistence.xml” and a “web.xml”. Explicit rules on how the values defined in those individual files are overridden by application-wide configuration needs to be defined. These rules would need to be defined amongst the different ways configuration is enabled, for example “application.xml” overriding the values set by annotations.
  9. Going a step further, it may be relevant to even provide a standard schema on how this information is persisted. Vendors may provide their extensions to it, but at least a basic schema would ensure some level of portability.A development database bundled with the application server would work during development stage. But typically a more enterprise and reliable database would be used during production. So one more step further, a standard way to connect to these databases would be useful.
  10. A typical EAR file may look like:

    The scope of how/where an annotation is defined needs to be clearly specified. Whether “application.xml” can be defined in a JAR file bundled in WEB-INF/lib in an EAR file ?

    If so, what are the overriding rules ?

    Can it only be specified on the top-level archive ?

    What happens if there is a conflict ?

  11. JSR 236 did not specify how different managed objects can be configured, and this is a gap in the existing specification. If JSR 236.next is not being planned or not planning to address it during Java EE 8 timeframe, then this JSR should attempt to address that.
  12. Different application servers have their own means to deploy multiple versions of an application. This allows multiple versions to be deployed but only one version to be enabled at a given time. It would be nice if application versioning can be addressed by this JSR.
  13. Pre/post hooks for deployment, and other stages, should be made available. These can be used by sysadmins to provision resources required during deployment/runtime.
  14. CDI events for different stages may be generated. This would allow different parties to listen, and react to them.
  15. A Java EE 8 application may not need any deployment descriptors of the past. Bundling either just this “application.xml”, or specifying the configuration information externally should be enough.
  16. Reload of configuration information should be possible, without deploying the archive.
  17. A REST schema of all the configuration information handled by the JSR will really simplify how vendors can easily build custom tools on it.
  18. Other frameworks like Ruby-on-Rails and Grails allow application-wide configuration and we should learn from them, and adopt their best practices.

Now that my own thoughts are listed here, here are some additional ones after reading the proposal …

  1. There is no mention in the JSR for an XML-based deployment descriptor. Even though non-Java EE components will be specified outside the scope of Java EE, but I think having a descriptor to specify the configuration for Java EE components is useful.
  2. +1 on not defining a new archive format and Anatole has explained it well in the blog.
  3. I strongly prefer the second approach integrate this new functionality with all existing JSRs as that keeps the approach simple, and scalable to any future specs as well. This JSR should define an overall framework, and how other JSRs would specify the configuration. Individual component JSRs then should leverage that and define the exact configuration points. Ideally, each component specification should have an explicit chapter dedicated for configuration.
  4. KISSing is good and I like the proposed simplistic approach of using a Map to store all this information.

What do do you think should be the scope of this JSR ?

Added a calendar reminder to revisit this blog in a year, and another one in +1 year, and see how many of these points actually make it in the spec.

Notes from Java EE meetup at Devoxx

conferences, javaee, , , ,

Devoxx provides a great opportunity for the key Java EE players to meet and discuss topics of interest. With the recently released Java EE 7 platform this year’s Birds of Feather session goal was to collect feedback on Java EE 7, ideas and wishes for Java EE 8, and any thing else that would encourage wider participation from the community.

David Delabassee (Oracle), David Blevins (Tomitribe), Peter Pilgrim (independent), Johan Vos (Lodgon), several JUG leaders, and other interested community members were present in this meetup. And of course I was there too!

Here are my notes from the discussion:

  • Feedback on Java EE 7: JCP 2.9 allowed different Java EE 7 JSRs to run transparently. Each project had a xxx-spec.java.net project (e.g. javaee-spec.java.net) and encouraged participation from the wider Java community. Interim spec drafts and API jar files were made available on the project Downloads area (e.g. javaee-spec downloads). Adopt-a-JSR allowed 20+ JUGs around the world to help shape up Java EE 7 platform.
  • API and Specification source: The source files of the API classes and source of the specification needs to be checked into the workspace. This will enable interested members to play with the API classes and provide alternative proposals. A text-based format (e.g. AsciiDoc) for the specification source is strongly preferred. This will allow community members to provide concrete proposals for specific sections from the specification. This will also help the specification lead to easily merge the submitted proposals in the existing specification. A git-based repository is strongly preferred as it enables and encourages collaboration. For example, source code for CDI API classes is available here and the text-based specification here. If  git-based repository cannot be created then a mirror between the existing repository and git must be established.
  • TCK should be open-sourced: A JSR consists of three components: Specification, Reference Implementation, and TCK. The specification is released under a fairly standard license. However as discussed above the source for API classes and specification needs to be made more publicly available. The Reference Implementations are released under an OSI-approved license. IBM led JSR 352 and the TCK is available under Apache License 2.0. Similarly Red Hat led JSR 346 and 349 and the TCK is available under Apache License 2.0. However TCKs for Oracle-led JSRs are available under this license (similar ones for other specifications). Open sourcing the TCK has been discussed multiple times in the past and Oracle already offers TCK to non-profits like Apache and Eclipse Foundation at no charge. However this still seems a last bit of “closed” piece in the otherwise fairly open and transparent process. TCK tests can also serve as extremely valuable resource for the developers to learn the technology. Adam Bien’s SmokeTests and Java EE 7 samples are turning out valuable resources for the developers and container implementors in lack of an open source TCK.A later discussion with David Blevins (founder of Tomitribe) revealed that it is very important to have TCK from the very beginning in order to implement the container and pass compliance eventually. Otherwise significant parts of the container need to be rewritten, as was done for Apache Geronimo, to get compliance. Open sourcing the TCK would certainly allow Tomitribe to work towards Java EE 7 compliance as well.
  • Testing: 90% of the attendees were using Arquillian for testing their apps against single/multiple containers. There was no need felt to file a JSR and standardize it as that could possibly stunt the innovation in this area.
  • Making contributions easier: Steps to contribute a patch to the Reference Implementation should be clearly listed. This is not restricted to but can typically include how to checkout and build workspace, high-level package overview, run smoke tests, steps to add new tests.
  • Potential topics for Java EE 8: Simpler security, standalone CDI, Action-based framework, Event-driven system, standard way of achieving high availability on application server, ability to generate native mobile apps with a Java EE backend.

All in all, Hildeberto Mendonça summarized in three words “Because we care” on why the attendees showed up for the 7pm BoF. If you do care, get involved!

WildFly 8 is getting dressed and Candidate Release 1 is now anyday!