I have Androud telephone connected via USB cable to my computer and I want to take screenshot when test fails:
I have the following code that returns error:
thisline returns error "File source = driver.getScreenshotAs(OutputType.FILE);" - is there any different solution ?
public String getScreenshotPath(String testCaseName, AppiumDriver driver) throws IOException {
File source = driver.getScreenshotAs(OutputType.FILE);
String destinationFile = System.getProperty("user.dir")+"//reports"+testCaseName+".png";
FileUtils.copyFile(source, new File(destinationFile));
return destinationFile;
}
it returns error:
java.lang.IllegalArgumentException: Illegal base64 character a
at java.base/java.util.Base64$Decoder.decode0(Base64.java:746)
at java.base/java.util.Base64$Decoder.decode(Base64.java:538)
at java.base/java.util.Base64$Decoder.decode(Base64.java:561)
at org.openqa.selenium.OutputType$2.convertFromBase64Png(OutputType.java:58)
at org.openqa.selenium.OutputType$2.convertFromBase64Png(OutputType.java:55)
at org.openqa.selenium.OutputType$3.convertFromBase64Png(OutputType.java:78)
at org.openqa.selenium.OutputType$3.convertFromBase64Png(OutputType.java:75)
at org.openqa.selenium.remote.RemoteWebDriver.getScreenshotAs(RemoteWebDriver.java:335)
at utils.AppiumUtils.getScreenshotPath(AppiumUtils.java:73)
at Appium.AppiumMaven.Listeners.onTestFailure(Listeners.java:47)
at org.testng.internal.TestListenerHelper.runTestListeners(TestListenerHelper.java:99)
at org.testng.internal.invokers.TestInvoker.runTestResultListener(TestInvoker.java:277)
at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:978)
at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:194)
at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:148)
at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at org.testng.TestRunner.privateRun(TestRunner.java:806)
at org.testng.TestRunner.run(TestRunner.java:601)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:433)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:427)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:387)
at org.testng.SuiteRunner.run(SuiteRunner.java:330)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1256)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1176)
at org.testng.TestNG.runSuites(TestNG.java:1099)
at org.testng.TestNG.run(TestNG.java:1067)
at org.testng.remote.AbstractRemoteTestNG.run(AbstractRemoteTestNG.java:115)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:251)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:77)
That's because there is an annoying thing Appium does when using it's driver to take a screenshot, but I'm not sure if this applies in your situation.
Can you output the Base64 in the console to check it's specific output? If the output is something like this:
"Z3Rlc2dyZXNncmdyZWFncmVzZ3Jlc2dyZWFncmVzZ3Jlc2dlaW93YWpm\n"
"ZW9ndGVzZ3Jlc2dyZ3JlYWdyZXNncmVzZ3JlYWdyZXNncmVzZ2Vpb3dh\n"
"amZlb2d0ZXNncmVzZ3JncmVhZ3Jlc2dyZXNncmVhZ3Jlc2dyZXNnZWlv\n"
"d2FqZmVvZ3Rlc2dyZXNncmdyZWFncmVzZ3Jlc2dyZWFncmVzZ3Jlc2dl\n"
"aW93YWpmZW9ndGVzZ3Jlc2dyZ3JlYWdyZXNncmVzZ3JlYWdyZXNncmVz\n"
"Z2Vpb3dhamZlb2d0ZXNncmVzZ3JncmVhZ3Jlc2dyZXNncmVhZ3Jlc2dy\n"
Then you should replace the "\n" to a blank "":
String screenshotBase64 = ((TakesScreenshot) driver).getScreenshotAs(OutputType.BASE64);
String replaceBase64 = screenshotBase64.replaceAll("\n","");
doSomethingWith(replaceBase64);
This related to some already known problem. Read https://github.com/appium/java-client/issues/1783
If you want to take screenshot for web app on android mobile devices, you must take screenshot as Base64 format and add this to DesiredCapabilites or UiAutomator2Options class:
UiAutomator2Options options = new UiAutomator2Options();
options.setNativeWebScreenshot(true);
For native app, I do not face this problem.
I have added below 2 dependencies and it worked for me.
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-api</artifactId>
<version>4.5.0</version> <!-- Upgrading this version to higher, will fail test script taking screenshot -->
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-remote-driver</artifactId>
<version>4.5.0</version> <!-- Upgrading this version to higher, will fail test script taking screenshot -->
</dependency>
I have initially added 4.6.0 and were showing same error, but now it worked with 4.5.0
Try this:
getScenario().embed(((TakesScreenshot)driver).getScreenshotAs(OutputType.BYTES)
instead of:
File source = driver.getScreenshotAs(OutputType.FILE);
String destinationFile = System.getProperty("user.dir")+"//reports"+testCaseName+".png";
FileUtils.copyFile(source, new File(destinationFile));
return destinationFile;
I have a piece of code which has JRecord related components and Maven cannot find the dependency for cb2xml, so all the code is red. I looked for info on the internet, but could not find much. So ICobolIOBuilder, JRecordInterface1 and everything related to JRecord cannot be found.
I will post my code, can anyone help me with the dependencies?
final ICobolIOBuilder ioBldr = JRecordInterface1.COBOL
.newIOBuilder(copyBookFile)
.setFont("cp273")
.setDialect(ICopybookDialects.FMT_MAINFRAME);
final AbstractLineReader reader = ioBldr.newReader(dataFile);
AbstractLine l;
while ((l = reader.read()) != null) {
System.out.println(">>>>>" + l.getFullLine());
System.out.print("<<<<<");
final FieldIterator iter = l.getFieldIterator(0);
while (iter.hasNext()) {
final AbstractFieldValue field = iter.next();
System.out.print("|" + field.getFieldDetail().getName() + "=" + field.asString());
}
System.out.println("");
}
reader.close();
The dependencies related to Cobol I have are:
<dependency>
<groupId>net.sf.cobol2j</groupId>
<artifactId>cobol2j</artifactId>
<version>1.5.4</version>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.6</version>
</dependency>
You need to build cb2xml with maven first.
If you downloaded JRecord from Source Forge, The source for cb2xml should be in the Source\OtherSource\cb2xml_package directory.
Other options for Getting cb2xml source are
cb2xml on sourceforge
cb2xml on GitHub
Please add following dependency in pom.xml file
<dependency>
<groupId>net.sf</groupId>
<artifactId>jrecord</artifactId>
<version>0.90.2</version>
</dependency
Add repository:
<repositories>
<repository>
<snapshots>
<enabled>true</enabled>
</snapshots>
<id>central</id>
<name>maven2</name>
<url>https://repo.maven.apache.org/maven2</url>
</repository>
<repository>
<snapshots>
<enabled>true</enabled>
</snapshots>
<id>pentaho</id>
<name>omni</name>
<url>https://nexus.pentaho.org/content/groups/omni</url>
</repository>
</repositories>
It will download all necessary files from Pentaho
Now you can do maven update and maven clean install
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>