|
From: <jas...@ma...> - 2005-04-06 16:06:49
|
On the ActiveMQ project we use Spring as our configuration mechanism to configure message brokers, their wire formats, transport connectors, persistence configurations etc. It works a treat. What we did to make things a little easier for end users (who faced with reams of beans with generic properties, can find configuration hard) - we made a custom Spring XML language, with our own schema, which extends the normal Spring XML language but constrains things a little - making it easier for folks to see how to configure things and providing better IDE-editor smart completion & better validation etc. e.g. here's the DTD... http://activemq.org/dtd/activemq.dtd (as you can see its based on a cut and paste of the Spring DTD to extend it; as spring's based on DTDs) e.g. <!DOCTYPE beans PUBLIC "-//ACTIVEMQ//DTD//EN" "http://activemq.org/dtd/activemq.dtd"> <beans> <broker> <connector> <tcpServerTransport uri="tcp://localhost:61616" backlog="1000" useAsyncSend="true" maxOutstandingMessages="50"/> </connector> <persistence> <!-- you can point this to a different datasource --> <jdbcPersistence dataSourceRef="derby-ds"/> </persistence> </broker> <beans> So first step; it'd be good if Spring used an XML Schema so we can just extend it :) Now all we do is provide our own BeanFactory implementation which is like a regular XmlBeanFactory but we transform the XML from our extended syntax into normal Spring, then let Spring do all the hard work. However here's a bigger thought. What if various different component authors wrote their own extended Spring XML languages ('XML marcros' if you like) for different subsystems. XML is all about being human/tool editable and new custom languages make it easier to edit & add better constraints. So the idea of new sub-languages is a good one. (e.g. Geronimo's custom XML could be based on Spring too; I'm sure other libraries/frameworks could add their own custom XML language - e.g. Drools or Hibernate specific stuff or webflow stuff, AOP stuff etc). What would really rock is if we could have a generic mechanism for registering XML languages at different namespaces - then freely mixing and matching these different XML configuration languages inside *any* standard Spring XML config file using the normal Spring bean factory implementations. e.g. imagine the <broker> element above being the nice, brief way to configure an ActiveMQ broker above. Sure we could do it more verbosely using <bean> and <property> tags; but the ActiveMQ language is simpler & easier to type/validate. But it'd be nice to mix and match this in any XML config in any spring use case. e.g. <beans> <!--- lets use ActiveMQ's custom XML along with some made up Drools XML too --> <language namespace="http://activemq.org/schema/3.0" class="org.activemq.spring.XmlDialectImpl"/> <language namespace="http://drools.org/rules" class="org. drools.SpringXMLThingy"/> <broker xmlns="http://http://activemq.org/schema/3.0" xmlns:drools="http://drools.org/rules"> <connector> <!-- lets add a drools rule base --> <drools:rulebase> <drools:rule> <drools:condition>x > 10</drools:condition> <drools:parameter name="foo"> <!-- back to regular Spring again here --> <ref>cheese</ref> </drools:paramater> </drools:rule> </drools:rulebase> </connector> </broker> <!-- regular Spring again --> <bean id="cheese" class="com.acme.Foo"> </bean> To give a concrete real use case for this; when using Spring to configure ActiveMQ's JCA container for Message Driven POJOs (which could use its own simplified XML language too), we often wanna deploy an embedded ActiveMQ message broker inside the JCA container. Right now rather than including a little XML fragment as above; we have to split things into separate files. Thinking generically; it'd be nice for folks to be able to register different XML 'short hand' libraries with Spring, using standard spring (rather than custom bean factories) to let all this kinda stuff integrate together cleanly. In principle, registering 'dialect handlers' with namespaces in the standard Spring XML configuration file reader is fairly trivial. The harder part is how to implement the transformation of some arbitrary XML element (say drools:rulebase) to regular Spring configuration stuff (say <bean class="org.drools.DefaultRuleBaseImpl">...</bean>). Right now in ActiveMQ we ended up using XSLT as the W3C DOM API is such a PITA to work with and we didn't wanna add a new dependency; but maybe we could come up with a pure Spring based 'XML macro' mechanism we could all integrate with? I'm wondering have others thought along these kinda lines - or is it just us :) James ------- http://radio.weblogs.com/0112098/ |