Spring IDE Blog

I was in London the other day to meet with Dave from Interface21 and two colleagues of mine (cheers to Scott and Lucas). One topic of the meeting was related to domain modeling. During the discussion we tried hard to come up with a decent name for a component in our domain model, but couldn’t figure out a descriptive name that would serve our needs well enough.

We were playing around with different names and - you know how that happens during meetings that take the whole day and you start loosing track for a couple of seconds - we started to look for names in other languages than English.

That moment I thought about a custom namespace that is properly the most useless one can think of: A translation of the Spring beans XSD into other languages. This idea sounds like non-sense in the first place, but on my way back at the Heathrow airport I couldn’t resist to think about it in more detail. Finally I ended up scratching a rapid prototype that allows to write bean definitions in my mother language:

Still, I don’t really see how a translation of the Spring beans XML configuration dialect into other languages can be useful for anyone, but there is already a request for translating Spring’s Exception message to other languages somewhere on the forums.

So what is the story of the post then?

There is one aspect of the preceding example, which I overlooked at the beginning, that could actually become quite useful. As you can see in the example there is not a single XML element from the original Spring dialect used to wire up two Beans. Certainly the syntax looks quite the same as plain Spring, but that is only an example. Even the root beans element is not used.

I wasn’t aware of the fact that with using Spring 2.0 namespaces you can introduce your own DSL to configure components without being tied to Spring’s XML syntax in any way. I haven’t seen a namespace example before that doesn’t use the beans element at least at the root level.

Consequently Spring allows mixing configuration files with different syntax in one ApplicationContext. So you can use a configuration file for your domain services or repositories that uses a Domain Specific Namespace and others for your technical infrastructure services, like transaction or security, that leverage the power of Spring’s XML syntax.

That could be very handy if you are working on a project that applies pattern following DDD. Furthermore that shows how flexible the Spring container is in terms of XML configuration since the introduction of custom namespaces with version 2.0.

The prototype source code of the German namespace handler is available here.