Configuration in Java Source

The system configuration is hard-coded into the Java source, rather than being pulled for external sources. This is, to an extent, somewhat implicit for all applications that have text messages embedded in the source: those messages are themselves are form of configuration, one that internationalized applications store in property files in the application.

Features

• The configuration is stored in source, either as Java 5 annotations, or constants in the source itself.
• In web applications, some information can be embedded inside JSP pages.

Advantages

• All the IDEs handle quick-popup display of Javadocs, which can be useful for working with the values.
• Compile-time linkage guarantees that constants are defined, and that annotations are syntactically correct.
• Easy for developers to change the configuration, simply by editing the source.
• Java5 annotations can keep configuration metadata (table names) near the values (the persistent classes) that use it.
• String constants can be shared across all classes that use it.
• Keeps all configuration under SCM.

Disadvantages

• It is impossible to change the configuration without rebuilding the entire application.
• Only one configuration is possible. For many parts of an application, this is actually a feature, as it reduces the testing requirements.
• Very hard for the operations team to edit the application.
• Not all APIs offer programmatic configuration. For example, there is no standard Java Servlet container API, other than that newly drafted for version 3.0 of the specification. To configure a web-application, you need to use server-specific APIs.

SmartFrog support

SmartFrog does not support Java annotations; we have found such annotations fairly inflexible. The pure-annotation world of something like Hibernate or EJB3 works for simple use cases, but you soon discover that you need to change things. Once you start allowing ways for the annotations to be overridden, life has gets very complex indeed. Sometimes it is better to jump straight to configuration languages, provided they are powerful enough.

What SmartFrog does have is the CONSTANT and ICONSTANT references, that can extract string and integer constants from java classes and use them inside deployment descriptors. This is regularly used in SmartFrog's own test cases, in which the error message expected is extracted from the Java classes.

For example, the reference

expectedText CONSTANT org.smartfrog.services.os.java.LibraryArtifactImpl.ERROR_NO_DOWNLOAD;

Combined with the declaration in the class org.smartfrog.services.os.java.LibraryArtifactImpl of the static string:

public static final String ERROR_NO_DOWNLOAD = "The network policy prevents the download of ";

This would result in the value of expectedText being "The network policy prevents the download of ".

We don't (yet) have any way of getting other metadata from a class/annotation into deployment descriptors. Being able to pull class metadata and annotation values could be useful, in some cases.