I’ve just released a new version of springy, the JRuby-based alternative to Spring’s XML configuration format. It now has a “serialise-to-xml”-feature which allows you to write your whole config to a nicely formatted Spring XML file. Why would you want to do that ? In our case we’ve created a Ruby-based configuration framework modeled after Rails environments which pulls config files from different locations, deals with overrides and so on. The only downside is that this is pretty slow (especially when unit testing), hence the idea of serialising the whole context to XML.
The serialised XML config file is about twice the size of the springy context (~1600 vs. ~800 lines), which shows how expressive Ruby can be. A small example from our configuration:
DAOS = [ :ZoneDAO, :EmailDomainDAO, :DayDAO, :PreferenceDAO,
:WhatEverDao… ]
DAOS.each do |dao|
bean(dao, “daos.hibernate.#{dao}Hibernate”)
{|b| b.new(“sonarSession”)}
end
This snippet uses metaprogramming to create 20 odd DAOs in 8 lines of code.
Springy has matured since the first release when it was still in the proof-of-concept-stage. We’re using it successfully in Sonar, and there is no way we’ll ever go back to using XML for configuration. Anyway, XML is for girls, according to Hani.
My new favourite feature in JRuby is JavaUtilities.extend_proxy. Basically it allows you to extend an existing Java class with Ruby code. All instances of this class will then have additional Ruby methods on them. This can be handy to fix completely useless APIs like org.w3c.dom.Document. If you’ve ever used Ruby’s xml builder you will know what I mean.
JRuby allows us to do this:
JavaUtilities.
extend_proxy(‘com.sun…internal.dom.DocumentImpl’) {
def tag(sym, *args, &block)
#ruby code omitted
end
}
doc = DocumentImpl.new
doc.tag(“beans”) do
doc.tag(“bean”, “id”=>“mybean”) do
…
end
end
doc.validate!
doc.serialize(System.err)
DOM is finally usable! See serialization.rb for the full code.
