I'm trying to use axiom 1.2.22 with woodstox 6.2.6 to parse an XML document with a doctype. (I'm using OpenJDK 11 but that shouldn't make any difference.) I'm getting the same error that was mentioned in How to ignore DTD parsing in Apache's AXIOM :
Cannot create OMDocType because the XMLStreamReader doesn't support the DTDReader extension
According to https://issues.apache.org/jira/browse/AXIOM-475 that was supposed to be fixed with axiom 1.2.16, but it seems the bug is back again.
Example snippet:
InputStream is = Test.class.getResourceAsStream("xml-with-dtd.xml");
OMXMLParserWrapper builder = OMXMLBuilderFactory.createStAXOMBuilder(XMLInputFactory.newFactory().createXMLStreamReader(is));
OMElement result = builder.getDocumentElement();
Am I using incompatible versions? I also tried using woodstox 5.0.0, which throws the same error. I also verified that it's actually the woodstox XMLInputFactory when using XMLInputFactory.newFactory() that is used. These are the maven dependencies that I use (I've omitted some exclusions related to logging and duplicated classes):
<dependency>
<groupId>com.fasterxml.woodstox</groupId>
<artifactId>woodstox-core</artifactId>
<version>6.2.6</version>
</dependency>
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>stax2-api</artifactId>
<version>4.2.1</version>
</dependency>
<dependency>
<groupId>org.apache.ws.commons.axiom</groupId>
<artifactId>axiom-impl</artifactId>
<version>1.2.22</version>
</dependency>
<dependency>
<groupId>org.apache.ws.commons.axiom</groupId>
<artifactId>axiom-api</artifactId>
<version>1.2.22</version>
</dependency>
Update: Looks a lot like the axiom code tries to determine a DTDReader class to use from a configuration property. Unfotunately setting the property DTDReader.PROPERTY in the XMLInputFactory to any value results in the following stack trace:
Exception in thread "main" java.lang.IllegalArgumentException: Unrecognized property 'org.apache.axiom.ext.stax.DTDReader'
at com.ctc.wstx.api.CommonConfig.reportUnknownProperty(CommonConfig.java:167)
at com.ctc.wstx.api.CommonConfig.setProperty(CommonConfig.java:158)
at com.ctc.wstx.api.ReaderConfig.setProperty(ReaderConfig.java:35)
at com.ctc.wstx.stax.WstxInputFactory.setProperty(WstxInputFactory.java:400)
I'm not sure why it didn't work when I tried it with woodstox 5, but this little patch against axiom 1.2.22 solves the problem at least for woodstox 6.2.6:
Index: axiom-api/src/main/java/org/apache/axiom/util/stax/dialect/StAXDialectDetector.java
===================================================================
--- axiom-api/src/main/java/org/apache/axiom/util/stax/dialect/StAXDialectDetector.java (revision 1891409)
+++ axiom-api/src/main/java/org/apache/axiom/util/stax/dialect/StAXDialectDetector.java (working copy)
## -274,6 +274,7 ##
return new Woodstox4Dialect(version.getComponent(1) == 0 && version.getComponent(2) < 11
|| version.getComponent(1) == 1 && version.getComponent(2) < 3);
case 5:
+ case 6:
return new Woodstox4Dialect(false);
default:
return null;
Update:
Version 1.3.0 of axiom also fixes the problem.
I downloaded commons-net-3.1.jar on this website:
https://jar-download.com/maven-repository-class-search.php?search_box=org.apache.commons.net.ntp.NTPUDPClient
it worked fine, but now I get this error:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/net/ntp/NTPUDPClient
Caused by: java.lang.ClassNotFoundException: org.apache.commons.net.ntp.NTPUDPClient
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 1 more
Can someone help me to fix this problem? I already searched for a solution, but I just find android threads without a solution for my problem.
Edit: I am using javaSE-14 (java-JDK) and eclipse. I am using the standard javaSE-14 library and a new created library with commons-net-3.7.jar (from Uroš answer), but I still have the same error. (I am not using a maven projekt, I am using a normal java projekt)
I tried to install the jar into my pom.xml with this text:
<dependency>
<groupId>commons-net</groupId>
<artifactId>commons-net</artifactId>
<version>3.7</version>
<scope>system</scope>
<systemPath>
C:\Users\denni\Downloads\Apache jar\commons-net-3.7.jar
</systemPath>
</dependency>
I also tried the text that was written below, but I still have the same problem
<dependency>
<groupId>commons-net</groupId>
<artifactId>commons-net</artifactId>
<version>3.7</version>
</dependency>
import java.net.InetAddress;
import java.util.Date;
import org.apache.commons.net.ntp.NTPUDPClient;
import org.apache.commons.net.ntp.TimeInfo;
public class time {
public static void main(String[] args) throws Exception {
NTPUDPClient client = new NTPUDPClient();
client.open();
// use host name or IP address of target NTP server
InetAddress hostAddr = InetAddress.getByName("pool.ntp.org");
TimeInfo info = client.getTime(hostAddr);
info.computeDetails(); // compute offset/delay if not already done
Long offsetValue = info.getOffset();
Long delayValue = info.getDelay();
String delay = (delayValue == null) ? "N/A" : delayValue.toString();
String offset = (offsetValue == null) ? "N/A" : offsetValue.toString();
System.out.println(" Roundtrip delay(ms)=" + delay
+ ", clock offset(ms)=" + offset); // offset in ms
client.close();
}
}
Hi Hans and welcome to SO.
java.lang.NoClassDefFoundError is not the same as java.lang.ClassNotFoundException.
What is most likely happening to you is that you have included commons-net-3.1.jar, but that doesn't mean commons-net-3.1.jar doesn't depend on some other .jar.
You haven't posted what your classpath looks like or in which IDE you are working in, whatever the case may be I strongly suggest you avoid manually adding .jar files from random sources because:
You will get errors like this one, missing dependencies.
More importantly, it is insecure! You may include some malicious stuff without knowing, and let us be honest here - you sure ain't gonna decompile that .jar and check if it is fishy or not.
Ergo I recommend looking up Maven and how to use it with your IDE, there are plenty of tutorials online about it.
You can use https://mvnrepository.com/ to find the dependecy you need, for example the one you are looking for can be found here, and is currently at version 3.7.
To include it in you maven project all you would need to do is to add it to pom.xml
<dependency>
<groupId>commons-net</groupId>
<artifactId>commons-net</artifactId>
<version>3.7</version>
</dependency>
I am trying to switch our project from Drools 6.5.0.CR2 to 7.7.0.Final. (Don't ask me who had the idea to use a CR version in a production environment)
I had no problems changing my dependencies (no compilation errors) but I am now having problems running my drools network. I am now getting an UnnsupportedOperationException from KieSession.startProcess.
java.lang.UnsupportedOperationException
at org.drools.core.impl.StatefulKnowledgeSessionImpl$DummyInternalProcessRuntime.startProcess(StatefulKnowledgeSessionImpl.java:2166)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:1839)
I create my kie session like so in a KieHelper class we have created with the following constructor and getter:
public KieHelper(Collection<File> resources) throws ResolverException {
this();
KieFileSystem kfs = this.services.newKieFileSystem();
for(File f : resources) {
System.out.println(f.getPath());
try{
FileInputStream fis = new FileInputStream(f);
kfs.write(
f.getPath(),
this.services.getResources().newInputStreamResource(fis));
}catch (Exception e) {
throw new ResolverException(e);
}
}
KieBuilder kieBuilder = this.services.newKieBuilder(kfs).buildAll();
if (kieBuilder.getResults().hasMessages(Level.ERROR)) {
List<Message> errors = kieBuilder.getResults().getMessages(Level.ERROR);
StringBuilder sb = new StringBuilder("Errors:");
for (Message msg : errors) {
sb.append("\n " + prettyBuildMessage(msg));
}
throw new ResolverException(sb.toString());
}
KieContainer container = services.newKieContainer(services.getRepository().getDefaultReleaseId());
this.base = container.getKieBase();
}
public KieSession newKieSession() {
return this.base.newKieSession();
}
Then I try and start the session like so in the class that uses the KieHelper:
KieSession wm = this.kieHelper.newKieSession();
//insert facts into the session
wm.startProcess(this.getRuleId()); //this is throwing the exception
In Drools 6 this works fine. In drools 7 it does not. I am hoping someone knows what is going on.
EDIT1:
With Tibor's answer I double checked the classpath. We are also switching from an ant only build system, where we were placing all the jar files in the binaries folder using the Drools Engine distribution zip on the classpath manually to Maven. I added the dependencies to our pm as described by the documentation here.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-bom</artifactId>
<type>pom</type>
<version>7.7.0.Final</version>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.kie</groupId>
<artifactId>kie-api</artifactId>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
</dependency>
</dependencies>
But looking at the dependencies from maven the list is much smaller:
From maven:
antlr-runtime-3.5.2.jar
commons-codec-1.10.jar
drools-compiler-7.7.0.Final.jar
drools-core-7.7.0.Final.jar
ecj-4.4.2.jar
kie-api-7.7.0.Final.jar
kie-internal-7.7.0.Final.jar
kie-soup-commons-7.7.0.Final.jar
kie-soup-maven-support-7.7.0.Final.jar
kie-soup-project-datamodel-api-7.7.0.Final.jar
kie-soup-project-datamodel-commons-7.7.0.Final.jar
mvel2-2.4.0.Final.jar
protobuf-java-2.6.0.jar
slf4j-api-1.7.25.jar
xmlpull-1.1.3.1.jar
xpp3_min-1.1.4c.jar
xstream-1.4.10.jar
From the Drools Engine Distribution Zip
activation-1.1.1.jar
aether-api-1.1.0.jar
aether-connector-basic-1.1.0.jar
aether-impl-1.1.0.jar
aether-spi-1.1.0.jar
aether-transport-file-1.1.0.jar
aether-transport-http-1.1.0.jar
aether-transport-wagon-1.1.0.jar
aether-util-1.1.0.jar
ant-1.8.4.jar
ant-launcher-1.8.4.jar
antlr-runtime-3.5.2.jar
aopalliance-1.0.jar
cdi-api-1.2.jar
commons-codec-1.10.jar
commons-collections4-4.1.jar
commons-lang3-3.4.jar
curvesapi-1.04.jar
drools-beliefs-7.7.0.Final.jar
drools-compiler-7.7.0.Final.jar
drools-core-7.7.0.Final.jar
drools-decisiontables-7.7.0.Final.jar
drools-persistence-api-7.7.0.Final.jar
drools-persistence-jpa-7.7.0.Final.jar
drools-pmml-7.7.0.Final.jar
drools-scorecards-7.7.0.Final.jar
drools-templates-7.7.0.Final.jar
drools-verifier-7.7.0.Final.jar
ecj-4.4.2.jar
guava-20.0.jar
guice-4.0-no_aop.jar
hibernate-jpa-2.1-api-1.0.0.Final.jar
httpclient-4.5.3.jar
httpcore-4.4.6.jar
itext-2.1.7.jar
javassist-3.20.0-GA.jar
javax.inject-1.jar
javax.interceptor-api-1.2.jar
jaxb-core-2.2.11.jar
jaxb-impl-2.2.11.jar
jboss-jaxb-api_2.2_spec-1.0.4.Final.jar
jboss-transaction-api_1.2_spec-1.0.1.Final.jar
jcl-over-slf4j-1.7.25.jar
jsoup-1.8.3.jar
kie-api-7.7.0.Final.jar
kie-ci-7.7.0.Final.jar
kie-internal-7.7.0.Final.jar
kie-soup-commons-7.7.0.Final.jar
kie-soup-maven-integration-7.7.0.Final.jar
kie-soup-maven-support-7.7.0.Final.jar
kie-soup-project-datamodel-api-7.7.0.Final.jar
kie-soup-project-datamodel-commons-7.7.0.Final.jar
maven-aether-provider-3.3.9.jar
maven-artifact-3.3.9.jar
maven-builder-support-3.3.9.jar
maven-compat-3.3.9.jar
maven-core-3.3.9.jar
maven-model-3.3.9.jar
maven-model-builder-3.3.9.jar
maven-plugin-api-3.3.9.jar
maven-repository-metadata-3.3.9.jar
maven-settings-3.3.9.jar
maven-settings-builder-3.3.9.jar
mvel2-2.4.0.Final.jar
org.eclipse.sisu.inject-0.3.2.jar
org.eclipse.sisu.plexus-0.3.2.jar
plexus-cipher-1.7.jar
plexus-classworlds-2.5.2.jar
plexus-component-annotations-1.6.jar
plexus-interpolation-1.21.jar
plexus-sec-dispatcher-1.3.jar
plexus-utils-3.0.22.jar
poi-3.15.jar
poi-ooxml-3.15.jar
poi-ooxml-schemas-3.15.jar
protobuf-java-2.6.0.jar
slf4j-api-1.7.25.jar
stax-api-1.0-2.jar
wagon-http-3.0.0.jar
wagon-http-shared-3.0.0.jar
wagon-provider-api-3.0.0.jar
xmlbeans-2.6.0.jar
xmlpull-1.1.3.1.jar
xpp3_min-1.1.4c.jar
xstream-1.4.10.jar
I must be missing something for the maven dependencies which is not in the documentation.
EDIT2
So as a test I went back to building in our old ant only style and adding all the jars from the drools engine distribution zip to the dependencies and the runtime classpath but I still get the same error...
Looking at the lists though neither contains anything from jBPM from the looks of it. Looking at our old source control system we do have jbpm jars there for 6.5.0. Are these these distributed separately I am guessing?
(Damn I cannot comment till I have 15 rep.)
It could be you don't have jBPM dependencies in your project. In such case I think Drools uses a dummy provider for processes that has no capabilities. But I am not 100% sure about this.
The following code worked fine in Java 7
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
String xmlString = '<xml ..... ';
StringReader reader = new StringReader(xmlString);
JAXBContext jc = JAXBContext.newInstance(MyClass.class);
Unmarshaller unmarshaller = jc.createUnmarshaller();
MyClass myClass = (MyClass) unmarshaller.unmarshal(reader);
....
Now we had to upgrade to Java 8 and now I get this exception when executing the code:
Sep 03, 2014 1:42:47 PM com.sun.xml.internal.bind.v2.util.XmlFactory createParserFactory
SCHWERWIEGEND: null
org.xml.sax.SAXNotRecognizedException: Feature: http://javax.xml.XMLConstants/feature/secure-processing
at org.apache.xerces.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:100)
at com.sun.xml.internal.bind.v2.util.XmlFactory.createParserFactory(XmlFactory.java:114)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getXMLReader(UnmarshallerImpl.java:139)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:214)
I know that there is a question targeting a similar problem, but stepping back to java 7 is not a solution for me.
I tried to add the following maven dependency
<dependency>
<groupId>javax.xml</groupId>
<artifactId>jaxp-api</artifactId>
<version>1.4</version>
</dependency>
but that did not change the result, so I removed it (thanks to #BlaiseDoughan for the information, that this is included in Java 6)
Any hints are welcome, many thanks.
We had a similar issue - our head developer found a solution that works for us.
We added this dependency to a couple of our pom.xml files
For those that care, the unit tests in Sonar that were failing were apparently failing because Cobatura by default pulls in an old version of xerces. The version it pulls in is incompatible with JAX-B in Java 8. The library is not used in production code – just Cobatura. Therefore, the fix was to add a test dependency on a more recent version of xerces (2.11.0). This is done by adding the dependency to the pom file:
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.11.0</version>
<scope>test</scope>
</dependency>
Xerces impl is the main culprit here. Remove it. Jdk has inbuilt jaxb parser, you don't need this.
so, if that dependency is coming from a parent project in case of maven
use a exclusion tab in case you can't directly remove it.
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
The reason this problem is so hard to detect is because, when you usually write a jaxb unmarshalling code
you will do a unmarshalling on a try block and then catch jaxb exception and then do whatever with the error.
But this culprit parser of a jar (xercesimpl) throws a runtime exception in the middle causing error to not
get logged and will be only be detected after careful debugging. Look at the code snippet below
try {
JAXBContext context = JAXBContext.newInstance(YourClass.class);
Unmarshaller unmarshaller = context.createUnmarshaller();
YourClass object = (YourClass)unmarshaller.unmarshal(new StringReader("SomeXmlInString"));
}
catch (JAXBException e){
e.printStackTrace();
}
Here xercesImpl causes the unmarshaller to use some other sax parser (instead of the regular jaxb parser)
causing it to throw different exception which
won't be caught in our catch block which is expecting a jaxbexception or one of its subclasses.
Another possible solution to this is to add system variables:
I used these in the maven tomcat plugin which worked for me:
<javax.xml.parsers.DocumentBuilderFactory>com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl</javax.xml.parsers.DocumentBuilderFactory>
<org.xml.sax.parser>com.sun.org.apache.xerces.internal.parsers.SAXParser</org.xml.sax.parser>
<javax.xml.parsers.SAXParserFactory>com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl</javax.xml.parsers.SAXParserFactory>
But you should also be able to set as follows:
java -Dorg.xml.sax.parser="com.sun.org.apache.xerces.internal.parsers.SAXParser" \
-Djavax.xml.parsers.DocumentBuilderFactory="com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl" \
-Djavax.xml.parsers.SAXParserFactory="com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"
or even use System.setProperty:
System.setProperty("org.xml.sax.driver", "com.sun.org.apache.xerces.internal.parsers.SAXParser");
System.setProperty("javax.xml.parsers.DocumentBuilderFactory","com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
System.setProperty("javax.xml.parsers.SAXParserFactory","com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl");
It was a dependency problem.
Here is my way how I solved the problem:
Make a new maven project, with that simple pieces of code, I attached below, the programm crashed normally with an error, that the structure couldn't be parsed which is ok.
Copy your dependencies into the project pom.xml, now the programm should crash (as described above)
no you remove dependencies after your favoured method (good guessing, Bisection , 1-by-1 ..) to find the "bad" dependency. Maybe someone has a better (more professional) method, this one worked for me.
now you can descide what to do, maybe a new version is available, in our case it was out own package of a colleage, where he included a package of a colleage, which i could exclude.
public class Test {
public Test() {
}
public static void main(String[] args) {
try {
StringReader reader = new StringReader("<xml></xml>");
JAXBContext jc = JAXBContext.newInstance(TestXML.class);
Unmarshaller unmarshaller = jc.createUnmarshaller();
TestXML testXMLs = (TestXML) unmarshaller.unmarshal(reader);
} catch (JAXBException e) {
e.printStackTrace();
}
}
}
and the testXML class
#XmlRootElement(name="rss")
#XmlAccessorType(XmlAccessType.FIELD)
public class TestXML {
public TestXML() {
}
#XmlElementWrapper(name="channel")
#XmlElement(name="item")
private int i ;
public int getI() {
return i;
}
public void setI(int i) {
this.i = i;
}
}
BTW: In my case it was
<dependency>
<groupId>jcs</groupId>
<artifactId>jcs</artifactId>
<version>1.3</version>
</dependency>
Hope that helps.
An implementation of JAXB has been included in Java SE since version 6. If you remove the Maven dependency (which is probably causing a version conflict), everything should work.
Both Bernard and Blaise's answers were very helpful. In my case, since I am using JDK 7, the solution was to exclude the xerces subdependency that was being included by one of my dependencies:
<dependency>
<groupId>org.apache.axis</groupId>
<artifactId>axis</artifactId>
<version>1.4.1-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xmlParserAPIs</artifactId>
</exclusion>
</exclusions>
</dependency>
I resolved this problem on my project with the second Mitch ‘solution but just with
java -Djavax.xml.parsers.SAXParserFactory="com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"
Using SAXparser can be a nightmare. This is the most widely used XML parser in java and every one have end up using either directly or indirectly. JDK 8 have JAXB already available . So if you are using JDK 8 then only possible way should be removing the maven dependency.
I had this issue as well so I tried removing the maven dependency but not happened. Then I thought why not revert to older version if java and VOILLA I got success. I am using jdk 7 currently and my tests run smoothly. I guess this is the only solution.
Try to create a XML Document and unmarshal it. It was worked for me.
JAXBContext jc = JAXBContext.newInstance( Message.class );
InputStream stream = new ByteArrayInputStream( string.getBytes( StandardCharsets.UTF_8 ) );
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse( stream );
Unmarshaller unmarshaller = jc.createUnmarshaller();
Message msg = ( Message ) unmarshaller.unmarshal( doc );
We also met the issue and noticed that you need to keep the jdk version and jre version the same, otherwise will exist the version mismatch caused the issue.
The guys who met the issue use jdk1.6 and jre 1.8, when changed to both jdk1.6, the issue gone.
I had faced similar issue, this issue occurs when there is big difference in versions of xerces jar and xercesImpl jar. To solve this, I used xerces-2.9.0 and xercesImpl-2.9.1 and the issue gone.
I had a similar issue while trying to solve the sonar vulnerability java:S2755.
SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // added (for sonar)
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // added (for sonar)
After adding those two lines the first setProperty() call threw a SAXNotRecognizedException.
I guess this happened because there were multiple implementations available of XMLSchemaFactory, one of them being included in the JDK.
My solution was to run mvn dependency:tree on the project and search for any occurences of "xerces". I found two dependencies which I excluded from all dependencies that used them:
<dependency>
<!-- ... -->
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<!-- ... -->
<exclusions>
<exclusion>
<groupId>com.rackspace.apache</groupId>
<artifactId>xerces2-xsd11</artifactId>
</exclusion>
</exclusions>
</dependency>
I had the same issue and was fixed by setting JVM arguements as
-Djavax.xml.accessExternalDTD=all -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
I have following code
static {
wsAuthenticate = WsAuthenticate.Factory.newInstance();
...
}
which calls
public static final SchemaType type = (SchemaType)
XmlBeans.typeSystemForClassLoader(WsAuthenticate.class.getClassLoader(),
"schemaorg_apache_xmlbeans.system.sDE164C7F4147229ECE15396F7FA5432D")
.resolveHandle("wsauthenticate751ftype");
in jar file containing .xsb files.
I have used following jar files
xBean1.0.3.jar
xmlBeans2.3.0.jar
xmlSchema1.4.7.jar
But I am facing following exception:
java.lang.NoSuchMethodError: org.apache.xmlbeans.XmlBeans.typeSystemForClassLoader(Ljava/lang/ClassLoader;Ljava/lang/String;)Lorg/apache/xmlbeans/SchemaTypeSystem;
at com.travis.webservices.WsAuthenticate.<clinit>(WsAuthenticate.java:19)
at com.travis.webservices.WsAuthenticate$Factory.newInstance(WsAuthenticate.java:119)
at com.mmi.api.ticketvala.TicketWalaMain.<clinit>(TicketWalaMain.java:64)
Exception in thread "main"
at :
XmlBeans.typeSystemForClassLoader(WsAuthenticate.class.getClassLoader(), "schemaorg_apache_xmlbeans.system.sDE164C7F4147229ECE15396F7FA5432D").resolveHandle("wsauthenticate751ftype");
What could be the reason and how to solve it?
This typeSystemForClassLoader method is introduced in version (2.1.0) . See javadoc checking with previous versions you can see this method is missing.
<dependency>
<groupId>xmlbeans</groupId>
<artifactId>xbean</artifactId>
<version>2.1.0</version>
</dependency>
I was also getting same exception when reading .xlsx file
org.apache.poi.POIXMLException: java.lang.reflect.InvocationTargetException
Caused By :java.lang.NoSuchMethodError: org.apache.xmlbeans.XmlBeans.typeSystemForClassLoadern
Then I"ve removed my old xmlbeans-2.0.jar and put the latest xmlbeans-2.3.0.jar containing this method and it is solved now
adding this dependency solved my problem:
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>ooxml-schemas</artifactId>
<version>1.3</version>
</dependency>