Menu
▾
▴
Re: [Springframework-developer] integrating custom XML spring dialects into the standard Spring XML config file
|
From: Rod J. <ro...@in...> - 2005-04-06 16:11:22
|
James We have talked about this and I even gave an example of possible mechanisms at TSSJS last month. I think it's important. We need to get 1.2 out the door now, but this is one of the highest priority features for 1.3 IMO. We should probably schedule a full discussion of this after all 1.2 issues are resolved. Good input here. Rgds Rod jas...@ma... wrote: > 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/ > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- Rod Johnson Interface21 - Spring Services from the Source http://www.springframework.com Founder, Spring Framework: http://www.springframework.org Author, "Expert One-on-One J2EE Development Without EJB" (May 2004, with Juergen Hoeller). http://www.amazon.com/exec/obidos/ASIN/0764558315/ Author, "Expert One-on-One J2EE Design and Development" (October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ ____________________________________________________ Interface21 Limited Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY Registered in England and Wales No. 5187766 ____________________________________________________ |
