Re: [Springframework-developer] Extensible XML processing in Spring: prototype version available in CVS HEAD

[Fredrik L. <fre...@ch...>]

The functionality described seems nice and unobtrusive.

Switching to XSD however, would be a disaster. Not only would you add more  
dependencies to spring to support XSD validation, you would also force an  
unneccesary, and in my opinion bad, technology choice on spring users if  
they want to take advantage of the custom xml functionality.

Please go ahead and add the custm xml functionality, but in the Spring  
spirit, keep the validation implementation pluggable.

Regards
Fredrik Lindgren

On Thu, 09 Jun 2005 17:27:56 +0200, <jas...@ma...> wrote:

> Quite a few folks have wanted some way to extend/enhance Spring's XML  
> configuration file mechanism to provide more concise XML with richer XML  
> validation (through schemas and XSD extension etc). Here's some  
> background ideas...
> http://article.gmane.org/gmane.comp.java.springframework.devel/8301/ 
> match=neater+xml++xsd
>
> Yet another project I work on, ServiceMix, needed this - and I didn't  
> have the heart to go down the XSLT route I've done before (e.g. on  
> ActiveMQ) - so I thought I'd experiment actually working on Spring to  
> provide an 'XML extension point' for XML configuration files.
>
>
> Example
> =======
> First here's the example of what the XML looks like in ServiceMix  
> before, using standard Spring - then afterwards with the 'XML  
> extensions' so you can see the kind of thing I mean.
>
> regular Spring config.
> http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ 
> org/servicemix/jbi/config/example-spring.xml?rev=HEAD&view=auto
>
> extended Spring
> http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ 
> org/servicemix/jbi/config/example.xml?rev=HEAD&view=auto
>
> Now ServiceMix users can use a *much* more concise XML, if they want -  
> we can easily add an XSD that can validate the ServiceMix model much  
> better - but we can still mix and match all the great Spring XML stuff  
> in there too. Its just a couple of trivial, simple macros (<components>,  
> <component> and <qname>) to simplify the XML.
>
>  From ServiceMix's perspective, we've implemented these new tags in the  
> XML using a couple of pretty-trivial classes.
>
> The neat thing about this is that folks can now start to mix and match  
> custom XML languages with the Spring XML. e.g. folks building Geronimo's  
> web, JCA and EJB containers can use Spring XML to deal with J2EE  
> deployment descriptors, but allow  those files to include Spring XML too!
>
>
> Implementation
> ============
> Now we could use inheritance to add custom XML processing (we did this  
> in ActiveMQ) - each library developer would then provide their own  
> definition reader / bean factory implementation; the problem with that  
> is there are so many kinds of bean factory & application context and  
> many ways to make them - having a custom bean factory didn't seem a  
> clean solution. Plus I'd like us to mix and match different extensions  
> together into the same Spring XML document. So I decided to try add a  
> 'META-INF/services/' style of auto-discovery.
>
> The basic idea is that the standard spring configuration mechanism, will  
> parse the regular Spring XML elements, but any new ones it doesn't  
> recognise, it will see if there is an ElementProcessor class registered  
> for the given element name (using namespaces too if need be). An  
> ElementProcessor is a trivial little plugin interface allowing folks to  
> turn any-old-XML into regular Spring <bean> <property> elements.
>
>
> Using XML extensions
> ================
>
> So if you parse the this example 'extended' spring XML, with the latest  
> CVS HEAD and the ServiceMix jar on your classpath...
> http://cvs.servicemix.codehaus.org/servicemix/base/src/test/resources/ 
> org/servicemix/jbi/config/example.xml?rev=HEAD&view=auto
>
> it will automatically parse these new XML extensions! (To use the  
> ServiceMix example above, since it uses arbitrary XML namespaces, you  
> have to turn of XML validation to avoid using the DTD (*))
>
> The neat thing is, different folks can now provide different extensions  
> on the classpath. So we could have groovy, activemq, servicemix,  
> geronimo-jca and geronimo-ejb, all making their own extensions, having  
> their own XSDs and all used freely inside a single XML document.
>
>
> Impact
> =====
> As it turns out, the impact on the code was surprisingly small and the  
> entire thing only took about a day to implement - most of which was on  
> the ServiceMix side of things (which is much less than the XSLT took to  
> get right on ActiveMQ! :). The impact on the Spring codebase is a couple  
> of fairly straightforward small methods added to the current parser, 1  
> new extension interface (ElementProcessor) and an optional helper class,  
> ElementProcessorSupport that wraps up a bunch of useful helper methods  
> for transforming DOM nodes and adding Spring XML elements.
>
> Due to the minimal impact of these changes & ease of backing them out  
> again, I've gone ahead and checked them straight in. Please take a look  
> and see what you think. I'm using ServiceMix (http://servicemix.org/) as  
> the test case right now; if there's general agreement among the team  
> with this approach, I'll add some spring specific test cases into CVS to  
> test it out inside the spring unit test suite.
>
>
> Remaining Issues
> =============
> This whole spike was surprisingly simple to do and had minimal impact on  
> Spring. (*) The only gotcha was, Spring uses XML validation by default -  
> which forces a DOCTYPE to be specified - and DOCTYPEs don't like  
> arbitrary namespaces to be used. So I've added an xmlValidating property  
> on AbstractXmlApplicationContext and a new constructor on BeanFactory so  
> you can turn off validation if you want to. (There could be other places  
> in the code that might need to allow validation to be turned off, but  
> that should do for a start).
>
> I guess if we had a Spring XSD, then we could enforce validation all the  
> time and folks who wish to extend the XML must specify one more more XSD  
> references in the XML?
>
> Thoughts?
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you  
> shotput
> a projector? How fast can you ride your desk chair down the office luge  
> track?
> If you want to score the big prize, get to know the little guy. Play to  
> win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>



-- 
Fredrik Lindgren