JAXBElements generated from wsdl in Mule - jaxb

We have a wsdl that we want to use in Mule studio. We generated the Java classes through the CXF component. There are a lot of elements in the schemas that are like this :
<xs:element minOccurs="0" name="SortIndex" nillable="true" type="xs:string"/>
In the generated Java classes, we get them as JAXBElement which is not really nice as it is hard to work with those in the DataMapper. I saw that this behavior can be overriden by providing jaxb bindings. However, this is how our wsdl looks now:
<wsdl:portType name="ILegacy">
<jaxws:bindings
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="src\main\resources\Legacy.wsdl"
xmlns="http://java.sun.com/xml/ns/jaxws"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb">
<enableWrapperStyle>false</enableWrapperStyle>
<jaxb:globalBindings generateElementProperty="false"/>
</jaxws:bindings>
However, this doesnt change the generation of JAXBElements. Is there something wrong with this code?

Are you suing wsdl2java or xjc? or something else?
If you are using CXF wsdl2java or xjc pass in your binding file as a parameter to the command:
bindings123.xjb:
<jaxws:bindings
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="src\main\resources\Legacy.wsdl"
xmlns="http://java.sun.com/xml/ns/jaxws"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb">
<enableWrapperStyle>false</enableWrapperStyle>
<jaxb:globalBindings generateElementProperty="false"/>
</jaxws:bindings>
then use -b to pass the bindings file to jaxb:
xjc schema1.xsd schema2.xsd schema3.xsd -b bindings123.xjb

Related

integrating an xsd validator (lib or tool)

I am currently using a crossplatform c++ project (windows+linux) which will soon need an external xsd validator.
My plan is to:
either find a c++ library which does xsd validation (possibly a complex task)
or an existing tool which I could just launch as an external process (easier I believe; Xerces could be an option?)
I have a deep hierarchy of xsd files, so I need a solid tool for the job.
My question: I need some suggestions about some easy-to-integrate-yet-production-ready-solution.
My take for now is to use Xerces, the java version and just call it in a separate process.
Probably I need to wrap Xerces, since it seems to not allow xsd validation in the command line, directly, e.g. https://github.com/ndw/xjparse.
Thanks
You could use xmllint with the --schema option:
xmllint --noout --schema test.xsd test.xml
test.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="info" type="xs:string"/>
</xs:schema>
test.xml
<?xml version="1.0"?>
<info>abc</info>

JAXB generated classes of certain types implementing a custom interface

I am working on an application that uses XJC to generate Java POJOs from XSDs. There are dozens of schemas, and that number will grow. The application also needs to be able to handle different versions of the same schema, which means that I will have multiple schemas defining common types. I am trying to customize the bindings so that certain core types implement a common interface. The Inheritance plugin of JAXB2 Basics seems to do what I need, but I can't seem to nail the right syntax.
Here is the relevant part of my schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:my="http://example.com/core"
targetNamespace="http://example.com/core"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
...
<xs:complexType name="addressType">
<xs:sequence>
<xs:element name="Address" type="xs:string"/>
<xs:element name="City" type="xs:string"/>
<xs:element name="Province" type="xs:string"/>
<xs:element name="Country" type="xs:string"/>
<xs:element name="County" type="xs:string" minOccurs="0"/>
<xs:element name="PostalCode" type="xs:string"/>
</xs:sequence>
</xs:complexType>
...
</xs:schema>
... and this is what my custom binding file looks like:
<?xml version="1.0"?>
<jaxb:bindings
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:inheritance="http://jaxb2-commons.dev.java.net/basic/inheritance"
xmlns:my="http://example.com/core"
jaxb:extensionBindingPrefixes="inheritance"
version="2.1">
<jaxb:bindings scd="x-schema::my" xmlns:my="http://example.com/core">
<jaxb:globalBindings localScoping="toplevel">
<jaxb:serializable/>
<xjc:simple/>
</jaxb:globalBindings>
<jaxb:bindings scd="/type::my:addressType">
<inheritance:implements>com.mysite.validator.ValidatableAddress</inheritance:implements>
<!--<xjc:superInterface name="com.mysite.validator.ValidatableAddress"/>-->
</jaxb:bindings>
</jaxb:bindings>
</jaxb:bindings>
I'm using the scd approach, because in all the "traditional" binding examples that show how to use the inheritence plugin, schemaLocation is specified. I want to avoid having to specify schemaLocation because of our large (and growing) number of schemas. I don't want to have to change the binding file every time we add a new schema. So, scd seems like it will satisfy this requirement.
However when I run the build using the above binding, I get this:
[xjc] [ERROR] cvc-elt.1: Cannot find the declaration of element 'inheritance:implements'.
[xjc] line 18 of file:/dev/workspace/my_app/etc/schemas/bindings-common.xml
[xjc] failure in the XJC task. Use the Ant -verbose switch for more details
[xjc] classLoader = java.net.URLClassLoader#ebcdbb
[xjc] SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7#14562c5
If I comment out the inheritance:implements line and uncomment the xjc:superInterface line, the error goes away and the build completes successfully, but my AddressType classes don't implement the ValidatableAddress type.
Can the inheritence plugin be used with scd? Can xjc:superInterface be limited to only certain elements?
Cheers.
Author of jaxb2-basics here.
See this issue in XJC. In short, XJC for some reason does not allow custom/vendor customization elements in SCD bindings.
inheritance:implements is such customization element.
So no, this does not work due a problem in XJC.
I personally bind via schemaLocation and XPath but use a "virtual" schema location URI and rewrite it via catalogs.
SCD would have been a much better choice (you're absolutely right here) but it just does not work.
Update on virtual schema location and catalogs.
Here's an example of binding which customizes some complex type:
<jaxb:bindings
schemaLocation="http://schemas.opengis.net/wps/2.0/wpsCommon.xsd"
node="/xs:schema">
<jaxb:bindings node="xs:element[#name='Data']/xs:complexType">
<wildcard:lax/>
</jaxb:bindings>
</jaxb:bindings>
It is bound via schemaLocation and XPath. The schemaLocation is an existing URL, but in the build it is rewritten via catalog into the resource inside a Maven artifact:
REWRITE_SYSTEM "http://schemas.opengis.net" "maven:org.jvnet.ogc:ogc-schemas:jar::!/ogc"
So basically http://schemas.opengis.net/wps/2.0/wpsCommon.xsd will be loaded from the ogc-schema.jar!/ogc/wps/2.0/wpsCommon.xsd.
Using maven-jaxb2-plugin you can refer to binding files inside Maven artifacts as well:
<binding>
<dependencyResource>
<groupId>${project.groupId}</groupId>
<artifactId>ows-v_2_0</artifactId>
<resource>ows-v_2_0.jsonix.xjb</resource>
<version>${project.version}</version>
</dependencyResource>
</binding>
So, in combination, it allows writing binding files once and reuse them across modules.
But this was all a huge pain to figure out. I did it for the ogc-schemas project which is now some 50 heavily interconnected schemas. I heavily suffer from XJC drawbacks and issues, but this is the best possible at the moment. I even thought about forking and patching XJC, but this is far of effort limits I can afford.
So I've ended up with a number of mindblogging workarounds which somehow do the job at the end of the day.
Thanks to lexicore for the prompt and detailed answers. However that approach wasn't working for me, so I ended up with the following solution...
Because I am using Ant to invoke XJC, I ended up leveraging Ant's <copy filtering="true"...> capabilities to dynamically generate the binding file.
Here is my binding "template" file (bindings-common.xml):
<?xml version="1.0"?>
<jaxb:bindings
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:inheritance="http://jaxb2-commons.dev.java.net/basic/inheritance"
xmlns:my="http://http://example.com/core"
jaxb:extensionBindingPrefixes="inheritance"
version="2.1">
<jaxb:bindings>
<jaxb:globalBindings localScoping="toplevel">
<jaxb:serializable/>
<xjc:simple/>
</jaxb:globalBindings>
</jaxb:bindings>
<jaxb:bindings
schemaLocation="#bindingSchema#"
node="/xs:schema">
<jaxb:bindings node="//xs:complexType[#name='addressType']">
<inheritance:implements>com.example.validator.ValidatableAddress</inheritance:implements>
</jaxb:bindings>
</jaxb:bindings>
</jaxb:bindings>
Note this line:
<jaxb:bindings
schemaLocation="#bindingSchema#"
node="/xs:schema">
This variable will get populated by Ant for each of the schemas that I am processing:
<property name="jaxb.binding.template" value="../etc/form-schemas/bindings-common.xml"/>
<property name="jaxb.binding.file" value="${jaxb.src.dir}/bindings-common${schema.version}.xml"/>
<echo message="Filtering ${jaxb.binding.file} using template ${jaxb.binding.template}"/>
<copy file="${jaxb.binding.template}"
tofile="${jaxb.binding.file}"
filtering="true">
<filterset>
<filter token="bindingSchema" value="../../etc/form-schemas/${schema.version}/common.xsd"/>
</filterset>
</copy>
<xjc destdir="${jaxb.src.dir}"
extension="true"
schema="${schema.file}"
package="${package}"
binding="${jaxb.binding.file}">
<arg value="-episode"/>
<arg value="${jaxb.src.dir}/common${schema.version}.episode"/>
<arg line="-Xinheritance"/>
<!-- Plugins -->
<classpath>
<fileset dir="../build-libs/">
<!-- JAXB2 Basics library -->
<include name="jaxb2-basics-0.6.4.jar"/>
<!-- JAXB2 Basics library dependencies -->
<include name="jaxb2-basics-runtime-0.6.4.jar"/>
<include name="jaxb2-basics-tools-0.6.4.jar"/>
<include name="javaparser-1.0.8.jar"/>
<include name="commons-beanutils-*.jar"/>
<include name="commons-lang-*.jar"/>
<include name="commons-logging-*.jar"/>
</fileset>
</classpath>
</xjc>
</target>
Hopefully this will help future generations of JAXB victims.

Using JAXB episode files with wsimport

There are two WSDLs which share some of schemas they use to define their datatypes. Here is an example of one of the WSDLs:
<wsdl:definitions
name="FooService"
targetNamespace="http://xmlns.my.org/services/FooService/v001"
xmlns:srv="http://xmlns.my.org/services/FooService/v001"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:fault="java:org.my.exception"
...
>
<wsdl:types>
<xsd:schema>
<xsd:import namespace="java:org.my.exception" schemaLocation="../xsd/common/BusinessException.xsd"/>
<xsd:import namespace="http://xmlns.my.org/services/FooServiceMessages/v001" schemaLocation="../xsd/fooservice/FooServiceMessages_v001.xsd"/>
</xsd:schema>
</wsdl:types>
...
<wsdl:message name="BusinessException">
<wsdl:part element="fault:BusinessException" name="BusinessException"/>
</wsdl:message>
...
<wsdl:portType name="IFooService">
<wsdl:operation name="getItems">
...
<wsdl:fault message="srv:BusinessException" name="BusinessException"/>
</wsdl:operation>
...
</wsdl:portType>
...
</wsdl:definitions>
BusinessException.xsd is one of the common schemes.
I'm trying to generate Java code by these WSDLs with wsimport. It would be reasonable to compile common schemas separately from WSDLd and then reuse classes derived from these schemas while compiling WSDLs. For this purpose I've generated a JAXB episode file along with common Java code:
<bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
<bindings scd="x-schema::tns" xmlns:tns="java:org.my.exception">
<schemaBindings map="false">
<package name="org.my.integration.dto.common"/>
</schemaBindings>
<bindings scd="~tns:BusinessException">
<class ref="org.my.integration.dto.common.BusinessException"/>
</bindings>
</bindings>
<bindings scd="x-schema::tns" xmlns:tns="http://xmlns.my.org/BaseIdentifiers/v001">
<schemaBindings map="false">
<package name="org.my.integration.dto.common"/>
</schemaBindings>
<bindings scd="~tns:EntityIdentifierListType">
<class ref="org.my.integration.dto.common.EntityIdentifierListType"/>
</bindings>
<bindings scd="~tns:...">
<class ref="..."/>
</bindings>
...
</bindings>
</bindings>
http://xmlns.my.org/BaseIdentifiers/v001 namespace is filled with another common schema that's imported in FooServiceMessages_v001.xsd (actually in a schema that's imported in a schema that's ... that's imported in FooServiceMessages_v001.xsd).
Here is a wsimport call which I use to generate Java code:
wsimport -B-XautoNameResolution -Xnocompile -s ./../java/ -verbose -b ./bindings/fooservice/jaxws-bindings.xml -b ./bindings/fooservice/jaxb-bindings.xml -b ./bindings/common/common.episode -keep ./wsdl/FooService_v001.wsdl
The following error occurs on this call:
[ERROR] Schema descriptor {java:org.my.exception}BusinessException in message part "BusinessException" is not defined and could not be bound to Java. ...
BTW if a binding for BusinessException.xsd is described in a plain external JAXB binding file (not in a episode file) all works fine. Looks like wsimport has some problems with handling episode files which describe bindings for schemes which are imported in WSDL directly.
Is there a way to use episode files with wsimport for schemes directly imported in WSDL (like BusinessException.xsd in my case)?
As https://github.com/javaee/jaxb-v2/issues/514 says it is impossible to generate sources for WSDL using JAXB episodes.
Sun/Oracle engineers unable to implement necessary enhancement for 11 years (2008-2019). And recently Oracle thrown sources to Eclipse project (October 2018).
I generate WSDL binding without episodes, as final step I remove packages from common schema. For Gradle it looks like:
wsimport {
wsdl = file("${project.rootDir}/wsdl/PingService.wsdl")
bindings = files(...)
}
task('afterWsimport', type: Delete) {
delete new File(file(wsimport.javaDir), "com/bla/schema")
delete new File(file(wsimport.javaDir), "com/foo")
}
wsimport.finalizedBy(afterWsimport)
It seems that this is some kind of bug or incorrect behavior of wsimport. wsdl2java tool from Apache CXF lacks this problem.

Web service client cannot be created by JAXWS:wsimport utility

Whenever i try to create a Webservice from a wsdl url i get an Error window in Netbeans IDE. Where there is no package or reference like this.
Here is my stack trace.
parsing WSDL...
[ERROR] A class/interface with the same name "org.wi.link.action.Exception" is already in use. Use a class customization to resolve this conflict.
line 35 of file:/D:/Development/source/WebServiceProject/TestProject/src/conf/xml-resources/web-service-references/service/wsdl/urladdress/wionline/services/service.wsdl
[ERROR] (Relevant to above error) another "Exception" is generated from here.
line 30 of file:/D:/Development/source/WebServiceProject/TestProject/src/conf/xml-resources/web-service-references/service/wsdl/urladdress/wionline/services/service.wsdl
[ERROR] Two declarations cause a collision in the ObjectFactory class.
line 35 of file:/D:/Development/source/WebServiceProject/TestProject/src/conf/xml-resources/web-service-references/service/wsdl/urladdress/wionline/services/service.wsdl
[ERROR] (Related to above error) This is the other declaration.
line 30 of file:/D:/Development/source/WebServiceProject/TestProject/src/conf/xml-resources/web-service-references/service/wsdl/urladdress/wionline/services/service.wsdl
[ERROR] Two declarations cause a collision in the ObjectFactory class.
line 38 of file:/D:/Development/source/WebServiceProject/TestProject/src/conf/xml-resources/web-service-references/service/wsdl/urladdress/wionline/services/service.wsdl
[ERROR] (Related to above error) This is the other declaration.
line 32 of file:/D:/Development/source/WebServiceProject/TestProject/src/conf/xml-resources/web-service-references/service/wsdl/urladdress/wionline/services/service.wsdl
D:\Development\source\WebServiceProject\TestProject\nbproject\jaxws-build.xml:225: wsimport failed
BUILD FAILED (total time: 2 seconds)
I can also post jaxws-build.xml if required Thanks in advance.
Webservice cannot be created with wsdl , only webservice client(to consume WS) can be created using wsdl.
For me the problem solved , by mistake i was adding "Web Service Client" with incorrect wsdl url , i was adding http://localhost:8080/MyService/MyService?Tester, which is the ws tester url.
The correct url should be the WSDL url i.e. http://localhost:8080/MyService/MyService?WSDL
Steps followed:
1. Go to Project-war
2. Right Click New > WebService Client
3. Select WSDL URL, paste the WSDL url , give package name
And its done :)
For me the problem solved .
You can only create WS from scratch or from existing bean.
Hope this will help you.
Under the hood wsimport utinilty uses JAXB compiler, so actualy error is relevant to JAXB. As stated in JAXB guide, you have two options - use schemabindings or factoryMethod customization, though that depends on your WSLD and it might be not possible. Another option would be to rename conflicting types in your WSDL document.
Based on comment below lets assume that this is your schema:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="Exception">
<xs:sequence>
<xs:element minOccurs="0" name="Exception" nillable="true" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Exception">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="Exception" nillable="true" type="Exception"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
To gernerate same errors you might run xjc compiler:
/bin/xjc.sh schema.xsd
As mentioned above easyest way to fix this issue would be to rename complex type or element name. But to make things more interesting you might define JAXB customization
<jaxb:bindings xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="1.0">
<jaxb:bindings schemaLocation="schema.xsd">
<jaxb:bindings node="//xs:complexType[#name='Exception']">
<jaxb:factoryMethod name="TypeException"/>
<jaxb:class name="TypeException" />
</jaxb:bindings>
</jaxb:bindings>
</jaxb:bindings>
And try once more:
/bin/xjc.sh -b binding.xml schema.xsd
Same binding might be supplied to wsimport utility:
wsimport myService.wsdl -b binding.xml

Using dom4j DOMDocument to feed validator.validate(DOMSource) fails in java 1.6 (xsi:noNamespaceSchemaLocation is not allowed), works in 1.5

Using dom4j DOMDocument to feed validator.validate(DOMSource) fails in java 1.6 (with xsi:noNamespaceSchemaLocation is not allowed to appear in root element), works in 1.5
I'm finding the following problem quite intractable (OK, that's an understatement) - any insights will be appreciated. Currently it seems like the best idea is to drop dom4j in favour of e.g. XOM (http://stackoverflow.com/questions/831865/what-java-xml-library-do-you-recommend-to-replace-dom4j).
I've been validating in memory XML created from dom4j 'new DOMDocument()' - but this will not work with Java 6.
The following call to validate(source) of a dom4j (1.6.1) DOMDocument derived DOMSource works with Java 1.5.x but fails with Java 1.6.x:
public void validate() throws Exception {
SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
schemaFactory.setErrorHandler(null);
Schema schemaXSD = schemaFactory.newSchema(new URL(getSchemaURLString()));
Validator validator = schemaXSD.newValidator();
DOMSource source = new DOMSource(getDocument());
validator.validate(source);
}
getSchemaURLString() is also used to add the xsi:noNamespaceSchemaLocation attribute to the root node, i.e.:
xsi:noNamespaceSchemaLocation="http://localhost:8080/integration/xsd/fqlResponseSchema-2.0.xsd"
The exception follows:
Exception: org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'xsi:noNamespaceSchemaLocation' is not allowed to appear in element 'specialfields'.;
complex-type.3.2.2: Attribute 'xsi:noNamespaceSchemaLocation' is not allowed to appear in element 'specialfields'.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:417)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3182)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2659)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2066)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.beginNode(DOMValidatorHelper.java:273)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:240)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:186)
at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:104)
at javax.xml.validation.Validator.validate(Validator.java:127)
Here's the start of the XML - generated after disabling the call to validator.validate(source):
<?xml version="1.0" encoding="utf-8"?>
<meetings xsi:noNamespaceSchemaLocation="http://localhost:8080/integration/xsd/fqlResponseSchema-2.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
.............
</meetings>
And of the XSD:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="meetings">
<xs:complexType>
<xs:choice>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" ref="summary" />
<xs:element minOccurs="0" maxOccurs="unbounded" ref="meeting" />
</xs:sequence>
<xs:element ref="error" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="summary">
................
So my root element is being rejected because it contains a xsi:noNamespaceSchemaLocation attribute. And the schema itself does not specify that as a valid attribute of my root element?
At this point it seems to me that I need to give up on dom4j for this task and switch to one of the other solutions, for example as outlined here:
But I'd like to know what I've done wrong at any rate!
Thanks in advance.
I had the same issue, and I found the following documentation at
http://www.ibm.com/developerworks/xml/library/x-javaxmlvalidapi/index.html
Validate against a document-specified schema
Some documents specify the schema they expect to be validated against,
typically using xsi:noNamespaceSchemaLocation and/or
xsi:schemaLocation attributes like this:
<document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.example.com/document.xsd">
...
If you create a schema without specifying a URL, file, or source, then
the Java language creates one that looks in the document being
validated to find the schema it should use. For example:
SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
Schema schema = factory.newSchema();
However, normally this isn't what you want. Usually the document
consumer should choose the schema, not the document producer.
Furthermore, this approach works only for XSD. All other schema
languages require an explicitly specified schema location.
The reason seems to be that non-namespace aware JAXP SAXParser is being created and used (see Link).
And solution for different libs I found at www.edankert.com.

Resources