Issue Details (XML | Word | Printable)

Key: MULE-2231
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Dirk Olmes
Reporter: Cédric Vidal
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Mule

Add support for Spring 2 XML Schema based configuration files in SpringConfigurationBuilder

Created: 30/Aug/07 11:38 AM   Updated: 17/Dec/07 08:00 AM
Component/s: Modules: Spring
Affects Version/s: 1.4.1
Fix Version/s: 1.4.4

Time Tracking:
Not Specified

File Attachments: None
Image Attachments:

1. MuleBeanDefinitionReader_CallStack.jpg
(150 kB)
Environment:
Mule 1.4.1
Spring 2 XML Schema based configuration files
Issue Links:
Duplicate
 
Related
 

Labels:
User impact: Medium


 Description  « Hide
When using a Spring 2 XML Schema based configuration file (spring2-context.xml) with the SpringConfigurationBuilder like this:

SpringConfigurationBuilder builder = new SpringConfigurationBuilder();
builder.configure("mule-spring-conf.xml", "spring2-context.xml");

It fails with the following exception: org.xml.sax.SAXParseException: Document root element "beans", must match DOCTYPE root "null".

It looks like it is because the MuleBeanDefinitionReader class enforces DTD validation even if the validation used is XML Schema based:
http://svn.codehaus.org/mule/tags/mule-1.4.1/modules/spring/src/main/java/org/mule/extras/spring/config/MuleBeanDefinitionReader.java

The trunk seems to have this limitation also:
http://svn.codehaus.org/mule/trunk/mule/modules/spring/src/main/java/org/mule/extras/spring/config/MuleBeanDefinitionReader.java

Any workaround would be greatly appreciated in the meantime

Regards,

Cédric

PS: The full stack trace:

Exception in thread "main" org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 11 in XML document from resource loaded through InputStream is invalid; nested exception is org.xml.sax.SAXParseException: Document root element "beans", must match DOCTYPE root "null".
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:359)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:303)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:280)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:142)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:158)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:184)
at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:112)
at org.mule.extras.spring.config.MuleApplicationContext.loadBeanDefinitions(MuleApplicationContext.java:65)
at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:101)
at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:395)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:330)
at org.mule.extras.spring.config.MuleApplicationContext.<init>(MuleApplicationContext.java:46)
at org.mule.extras.spring.config.MuleApplicationContext.<init>(MuleApplicationContext.java:38)
at org.mule.extras.spring.config.SpringConfigurationBuilder.configure(SpringConfigurationBuilder.java:99)
at org.mule.extras.spring.config.SpringConfigurationBuilder.configure(SpringConfigurationBuilder.java:68)
at com.vecteurplus.synergies.esb.SynergiesEsb.<init>(SynergiesEsb.java:31)
at com.vecteurplus.synergies.esb.SynergiesEsb.main(SynergiesEsb.java:21)
Caused by: org.xml.sax.SAXParseException: Document root element "beans", must match DOCTYPE root "null".
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.rootElementSpecified(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:78)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:351)
... 16 more



 All   Comments   Work Log   Change History   Transitions   FishEye      Sort Order: Ascending order - Click to sort in descending order
Andrew Perepelytsya added a comment - 30/Aug/07 12:05 PM
I remember we had to specify either DTD or XSD, otherwise it didn't work. Perhaps refactoring the code to parameterize this setting and adding a Spring2ConfigurationBuilder (with a spring2 alias) is the least intrusive solution.

For Mule 2 that's not an issue, however.


Cédric Vidal added a comment - 30/Aug/07 12:25 PM
Indeed, but the place where the DTD validation is enforced is digged quite deep in the callstack starting from SpringConfigurationBuilder.

Doing a Spring2 specific version would require duplicating a lot of code just for enforcing XML Schema based validation.

What's more, it would prevent mixing DTD based and XML Schema based Spring configuration files which perfectly proper Spring usage.

Why not delegating fully the validation to the Spring code ? Spring code handles mixing validations schemes already.

BTW, thanx for the very quick reply

Regards,

Cédric


Dirk Olmes added a comment - 04/Sep/07 07:15 AM
Using spring's autodetect mechanism allows to use schemas now in all places that used to support DTDs before:
  • embedded config files
  • references to spring config files
  • constructing mule trhough spring config files

DTD still works, also.

r8176.


Cédric Vidal added a comment - 04/Sep/07 03:02 PM
Hi Dirk,

I tested r8176 and I confirm that it works great !

Thanx a lot

Kind regards,

Cédric


Robert Poole added a comment - 29/Nov/07 05:23 PM
Any idea when Mule 1.4.4 is supposed to be released? This bug actually affects me in a pretty fundamental way, as my company has standardized on Spring 2.0 style config, and we prefer to rely on defining additional name spaces to enable things like transactional annotation (which pretty much makes declaring a DOCTYPE not an option for us, as we're forced then to use schema-based validation regardless of what we'd like to do).

I can rely on the 1.4.4 snapshot for development, but I suspect someone will balk if we try to deploy a snapshot release into a production environment.


Nicholas Bower added a comment - 17/Dec/07 02:14 AM
I tried upgrading a project from 1.4.1 to 1.4.3, encountered this error and found this Jira entry. I have had to go back to 1.4.1 and am also waiting on a fix. I am surprised this is being given new feature status considering the error does not occur with 1.4.1.

Mule top-level config:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE mule-configuration PUBLIC "-//MuleSource //DTD mule-configuration XML V1.0//EN"
"http://mule.mulesource.org/dtds/mule-configuration.dtd">

<!-- This is a blank configuration file for the DataFeeds project -->

<mule-configuration id="master-config" version="1.0">

<description>Configuration for the the "DataFeeds" project</description>

<environment-properties>
<file-properties location="${MULE_ENVIRONMENT}/deployment.properties"/>
</environment-properties>

<container-context className="org.mule.extras.spring.SpringContainerContext">
<properties>
<property name="configFile" value="spring-master.xml"/>
</properties>
</container-context>

<agents>
<agent name="RMI" className="org.mule.management.agents.RmiRegistryAgent"/>
<agent name="JmxAgent" className="org.mule.management.agents.JmxAgent">
<properties>
<property name="connectorServerUrl" value="service:jmx:rmi:///jndi/rmi://localhost:1099/server"/>
<map name="credentials">
<property name="muleusername" value="mulepassword"/>
<property name="admin" value="secret"/>
</map>
</properties>
</agent>
</agents>

</mule-configuration>


And the Spring top-level config;


<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="${MULE_ENVIRONMENT}/deployment.properties"/>
</bean>

<import resource="spring-ingest.xml"/>
<import resource="spring-archive.xml"/>

</beans>


Andrew Perepelytsya added a comment - 17/Dec/07 08:00 AM
RTM: it's in the 1.4.4, which you can download a snapshot of.