April 2017
« Sep    
Your widget title

Posts Tagged ‘XSD’

PostHeaderIcon (long tweet) This page calls for XML namespace declared with prefix body but no taglibrary exists for that namespace.


On creating a new JSF 2 page, I get the following warning when the page is displayed:

Warning: This page calls for XML namespace declared with prefix body but no taglibrary exists for that namespace.


In the XHTML page, replace the HTML 4 headers:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

with XHTML headers:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
<html xmlns=""

PostHeaderIcon Why “contract first” approach won’t work with CXF or SpringWS for Axis-generated WSDLs


My previous subject was the following: considering a WSDL that was generated by Axis 2, develop a webservice with CXF and/or SpringWS in “contract first” (ie the contract seen as an API is given, Java code comes afterwards) approach.

It cannot work easyly, unless you are ready to spend time, money and energy in creating adapters and adding layers in your application architecture.


With CXF, the first step is to generate Java code with the wsdl2java embeded in Maven CXF plugin. The output is explicit:

Failed to execute goal org.apache.cxf:cxf-codegen-plugin:2.6.1:#wsdl2java on project PocEjb3: Rpc/encoded wsdls are not supported with #CXF

(cf my tweet)

RPC vs Encoded

Actually, the SOAP envelope has two ways to transport the message: RPC and Document. More detail is available here: Which style of WSDL should I use?
Axis 2 generates RPC/encoded webservice ; this method is deprecated, CXF does not support it.

Spring WS

I then tried to use Spring WS. I thought “Spring WS is only contract-first, it should work”. The first pitfall I fell on was that SpringWS bases on XSD files, not on actual WSDL. For instance, if you follow SpringWS tutorial, you will find such a block:

    <sws:dynamic-wsdl id="holiday" portTypeName="HumanResource" locationUri="/holidayService/"
<sws:xsd location="/WEB-INF/hr.xsd"/>

To workaround, you can specify use tag, such as:

<sws:static-wsdl id="precomputed-holiday" location="/WEB-INF/precomputed-holiday.wsdl"/>

Anyway, the next issue appears: SpringWS expects to deal with document webservices, ie blocks like:

<soapenv:Envelope xmlns:soapenv="" xmlns:sch="">
        <!--You may enter the following 2 items in any order-->

whereas Axis-generated WSDL look like:

<soapenv:Envelope xmlns:xsi="" xmlns:xsd="" xmlns:soapenv="" xmlns:int="http://interfaces.api.lalou.jonathan">
        <int:sayHello soapenv:encodingStyle=""/>

In other words, I have just fallen on the exact same issue as with CXF: SpringWS cannot support RPC/encoded WSDLs.

PostHeaderIcon Spring / Mule / CheckExclusiveAttributesException: The attributes of Element … do not match the exclusive groups …


I have the following block in my Mule config file:

<servlet:inbound-endpoint path="authenticationService" address="http://localhost:1234">

. Even though this block matches XSD constraints, it is illegal from a functionnal point of view.

I get the following stacktrace:

Offending resource: mule-config.xml; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [lalou/jonathan/mule-config.xml]; nested exception is org.mule.config.spring.parsers.processors.CheckExclusiveAttributes$CheckExclusiveAttributesException: The attributes of Element servlet:inbound-endpoint{address=http://localhost:1234, name=.authenticationService:inbound.157:inbound-endpoint.158, path=authenticationService} do not match the exclusive groups [address] [ref] [path]

Explanation and Fix

The exception is meaningful: for the tag <servlet:inbound-endpoint>, only one among the three following attributes is needed: path, ref and address.

To fix the issue, keep only the relevant attribute.

PostHeaderIcon Spring: Failed to read schema document


I try to deploy a Mule ESB configuration, using this XML:

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="" xmlns:xsi=""
 <pattern:simple-service name="authenticationService"
 type="direct" />

I get the following error:

Ignored XML validation warning
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document ''

Extended Stacktrace

2011-11-22 16:10:25,375 WARN  xml.XmlBeanDefinitionReader         - Ignored XML validation warning
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document '', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.

Notice that Mule ESB files are similar to classic Spring files. Of course, I first checked the pointed XSD was actually reachable.
Anyway, this error should be raised when your application, for any reason -firewall, proxies, network interruption-, cannot access the remote site where the XSD is hosted.


  • Copy the XSD to a local folder
  • Create a file spring.schemas
  • Make it available in the classpath in META-INF.
  • Add the following line
  • http\://

    The pattern is: missing resource (beware of escaping colon) = path in classpath of the local XSD

  • Rebuild, pack and run!

PostHeaderIcon Useful XSD

Following the post on widely used DTDs, here is a list of some XSD (aka XML Schemas):

File XSD
Maven pom.xml
<project xmlns="" xmlns:xsi=""
<weblogic-web-app xmlns="" xmlns:xsi="" xsi:schemaLocation="">
Maven assembly.xml
<assembly xmlns="" xmlns:xsi="" xsi:schemaLocation="">
<web-app version="2.4" xmlns="" xmlns:xsi="" xsi:schemaLocation="">
<web-app version="2.4" xmlns="" xmlns:xsi="" xsi:schemaLocation="">