Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.4.1
  • Fix Version/s: 1.4.4
  • Component/s: Modules: Spring
  • Labels:
    None
  • Environment:

    Mule 1.4.1
    Spring 2 XML Schema based configuration files

  • User impact:
    Medium
  • Similar Issues:
    None

Description

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

Issue Links

Activity

Hide
Andrew Perepelytsya added a comment -

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.

Show
Andrew Perepelytsya added a comment - 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.
Hide
Cédric Vidal added a comment -

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

Show
Cédric Vidal added a comment - 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
Hide
Dirk Olmes added a comment -

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.

Show
Dirk Olmes added a comment - 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.
Hide
Cédric Vidal added a comment -

Hi Dirk,

I tested r8176 and I confirm that it works great !

Thanx a lot

Kind regards,

Cédric

Show
Cédric Vidal added a comment - Hi Dirk, I tested r8176 and I confirm that it works great ! Thanx a lot Kind regards, Cédric
Hide
Robert Poole added a comment -

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.

Show
Robert Poole added a comment - 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.
Hide
Nick Bower added a comment -

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>

Show
Nick Bower added a comment - 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>
Hide
Andrew Perepelytsya added a comment -

RTM: it's in the 1.4.4, which you can download a snapshot of.

Show
Andrew Perepelytsya added a comment - RTM: it's in the 1.4.4, which you can download a snapshot of.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: