Spring rocks and I'm a fan of its XML configuration mechanism, but there are times when it can be a little verbose. On the ActiveMQ
project for example, we use Spring to configure the broker - but to
make it easier for users to know how to configure the broker, without
wading through the POJOs which make up the implementation, we provide a
neater XML configuration
language. This language is basically derived from Spring's XML, so you
can still use all of the neat Spring configuration mechanisms, but we
add some new types for the ActiveMQ broker which are documented and
described in ActiveMQ's schema.
To implement this mechanism in ActiveMQ we ended up writing our own
custom bean factory with our own derived spring parser which performs
XSLT on the XML before passing it into Spring. Not the cleanest of
solutions; I'm not a huge fan of XSLT, its often way simpler to use a
regular programming language (dynamically or statically typed :).
So for some time I've wanted a cleaner way of doing this - to extend
Spring's XML language to add new 'types' to make it easier for users to
edit without having to know the Java code intimately - along with
allowing XSDs to be developed to make UI tooling simpler.
A newer project, ServiceMix (an open source ESB server & JBI container) - started off using Spring
to configure JBI components and POJOs together into pipelines. This
worked - and it meant we could avoid writing lots of configuration code
- Spring does all that for you - though the XML was a little on the
verbose side. After a few hours hacking I added a little hook
into Spring (its in CVS HEAD right now, I hope the other Spring
developers like it enough to include it in 1.2.2 :) and hey presto
we've got a much neater XML configuration mechanism.
Here's a quick comparison.
The example creates a JBI pipeline, transforming a message (in a HelloWorld kinda way) using a Groovy script.
As you can see the extended XML is a much simpler configuration
mechanism and uses namespaces and QNames well. For end users they no
longer have to completely understand the internals of ServiceMix to be
able to configure JBI components together, the XML is much more concise
and we can easily generate a nicely documented and easy to validate XSD.
Yet we're still using the same Spring primitives (so a
can contain regular elements etc).
All this was implemented in ServiceMix with a couple of pretty trivial classes.
12:29:33 PM 
|
|
