Discussions

News: DeveloperWorks: XML technology to create dynamic Java properties

  1. Hierarchical Inherited Rule-Interpreted XML, introduced on IBM developerWorks, allows you to replace standard Java properties with dynamic versions. It provides for the definition of properties that are evaluated based on the state of the application using simple expressions or even Groovy expressions, and it lets you use only one properties file for multiple instances of the application. Some snippets from the article that show the capabilities of the library:
    The problem with the traditional use of Java properties is that you have an inflexible configuration that will cost you more in maintenance. Instead, you can avoid these limitations using Hierarchical Inherited Rule-Interpreted XML. You can use Hierarchical Inherited Rule-Interpreted XML to replace the standard Java properties with a dynamic version. This allows you to define properties that you can evaluate based on the state of the application. Hierarchical Inherited Rule-Interpreted XML also enables you to use one properties file for multiple instances of the application.
    The XML files have conditional elements embedded in the value attributes, as shown in the following lines: The property unit (which represents the loaded XML file) allows storage of elements (Maps) that provide values applied by the rules. For example, if we had a map with an element named "job" (with a value of "architect") we could store that under the key "user" and the news_max_items property would be evaluated as 10. Message was edited by: joeo@enigmastation.com

    Threaded Messages (5)

  2. Get rid of the xml entirely[ Go to top ]

    Why not just eliminate the XML entirely and just have pure groovy configuration? I suppose the basic complaint against that approach is that code/language-based configuration becomes too complicated quickly, while xml would theoretically restrict the user to more readable, simple settings. Although based on many ant scripts I've seen, XML wouldn't really constrain behavior in that way. Anyway, the XML schema/syntax looks a little too easy to spread around in the config file, such as someone placing an override at the end of the config file, and a maintainer taking two hours to figure out why the config value isn't "properly loading". I would prefer:       I'm trying to stay within the attribute-heavy style used. I work in a web framework that has lots of overriding and scoping rules associated with its config files (Documentum's Webtop) and they are very powerful, but I do waste a lot of time trying to find out why something isn't working right, only to find out later that another tier has overriden the settings I edited at a lower level.
  3. Another example[ Go to top ]

    XML gives us a well defined structure that is often useful to use to organize facts, information and rules. This technology can use many scripting languages and Groovy is just an example. The scripting allows for flexibility not available through static XML alone. The article only demonstrates one practical applicatoin of this technology, but you can think of this as a technology which allows you to construct living or dynamic XML documents which are determined by the current application state. If you prefer to define properties as you have listed in your example, that is actually already possible. It would look like: ${5}" ${10} ${5} In this case a default becomes the last value, as each value element is tested in order to see if it is valid. Basically, elements are invisible to the DOM if they have a condition that evaluates false. The underlying XML technology here would represent the XML as the following if say the user.job = 'project manager' ${5} Checkout the info here and take note of the screenshots in the upper right for more hints on applications of this technology. http://www.alphaworks.ibm.com/tech/hirixml Chad Meadows
  4. different, but mostly the same[ Go to top ]

    Hm. Not quite dissimilar to what Apache Commons configuration and my own hackathingy are doing. The configuration logic is provided with "parameters" and their value and the configuration itself has constraints. For example: news_max_items=5 news_max_items[job|developer]=5 news_max_items[job|architect]=10 For configuration I personally still prefer configuration files because of their readability (compare the lines above to the other examples). Often configuration is quite simple and straigh forward and XML feels like overkill. jdbcUrl[system|production]=jdbc:... jdbcUrl[system|testing]=jdbc:... However business rules are usually more complex, and I'm still searching for a nice and straight forward rules engine. Maybe this is it?
  5. Rule Engine[ Go to top ]

    However business rules are usually more complex, and I'm still searching for a nice and straight forward rules engine. Maybe this is it?
    Yes, good point. The application of properties is demonstrating only a small part of the capabilities of this technology. You can also think of the technology as a rule engine that can be applied against XML data. Or even think of it as a rule engine construction tool to some degree. Here's a pure XML example. I'm sure there have been many web sites who may have created a XML configuration to describe their navigation. Something like the following: Using this technology, we can apply rules to the XML as following: Now the edit link element will only be available if the current user's role is editor. Chad Meadows
  6. XML Hierarchy[ Go to top ]

    news_max_items=5 news_max_items[job|developer]=5 news_max_items[job|architect]=10
    This is a simple syntax, but typically the XML tends to look fairly clean as well with any modern XML editor and is also fairly easy to navigate in modern editors. Some of the additional advantages of using XML is the ability to leverage the tree structure to provide for additional capabilities like the following: Using XML as our configuration it is possible to use the hierarchy to imply a set of defaults. In this example, the 'news_max_items' attribute is inherited to all of the children of the top level element. The children then can override the default. The virtual representation of the above XML would be the following when using this technology: In cases where you need a tree structure this technology can be very useful to construct that definition in a very concise XML where you can use implied inheritance to define defaults. Chad Meadows