Our J2EE/Spring/Mybatis web application has been running fine for some time on Java 7 (on Centos), but recently we tried updating our JVM to Java 8, and now we get the following stack-trace on start up:
java.lang.RuntimeException: XPathFactory#newInstance()
failed to create an XPathFactory for the default object model:
http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException:
java.util.ServiceConfigurationError: javax.xml.xpath.XPathFactory:jar:file:/usr/local/tomcats
/test/webapps/tms/WEB-INF/lib/saxon-xpath-8.7.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: Illegal configuration-file syntax
at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:102)
at org.apache.ibatis.parsing.XPathParser.commonConstructor(XPathParser.java:261)
at org.apache.ibatis.parsing.XPathParser.<init>(XPathParser.java:121)
at org.apache.ibatis.builder.xml.XMLMapperBuilder.<init>(XMLMapperBuilder.java:75)
at org.apache.ibatis.builder.xml.XMLMapperBuilder.<init>(XMLMapperBuilder.java:70)
at org.apache.ibatis.builder.annotation.MapperAnnotationBuilder.loadXmlResource(MapperAnnotationBuilder.java:158)
at org.apache.ibatis.builder.annotation.MapperAnnotationBuilder.parse(MapperAnnotationBuilder.java:113)
at org.apache.ibatis.binding.MapperRegistry.addMapper(MapperRegistry.java:66)
at org.apache.ibatis.session.Configuration.addMapper(Configuration.java:651)
at org.mybatis.spring.mapper.MapperFactoryBean.checkDaoConfig(MapperFactoryBean.java:97)
our Saxon9.jar version = 9.1.0.8 (latest).
There are many different jars/dependencies involved in parsing xml/xslt in our application, and I don't want to try guessing what changes to make by trial and error. Does anyone know what could be causing this, or where to look first?
This problem is described here.
If you want to use Saxon with Java 8 you need to upgrade Saxon to a version >= 9.5.1.5
Related
I am trying to get Cassandra v2.1.17 running using Java 11 (Oracle), but cannot get it to startup. I have updated all the JVM args in cassandra-env.sh to the Java 11 equivalents, but I now get the following error on startup:
ERROR 14:48:10 Exception encountered during startup
java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: sun.misc.Unsafe.monitorEnter(Ljava/lang/Object;)V
at com.google.common.base.Throwables.propagate(Throwables.java:160) ~[guava-16.0.jar:na]
...
...
...
Caused by: java.lang.NoSuchMethodError: sun.misc.Unsafe.monitorEnter(Ljava/lang/Object;)V
I have done a good bit of looking about and it seems that this class was removed in Java 9, or at least deprecated, but was still accessible using --add-modules=jdk.unsupported. Adding this to my JVM args didn't help.
Is it possible to run Cassandra 2.1.17 on Oracle Java 11? I can see that the class is still in OpenJDK 11 (https://hg.openjdk.java.net/jdk/jdk11/file/6889f13694c6/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java) but I am stuck using Centos6 and cannot find an install for it.
#MeanwhileInHell, JDK 11 support for Apache Cassandra(R) was explored in the recent Cassandra 4.0 version only and I don't think it's available in very older and unsupported versions like 2.x. Please see https://cassandra.apache.org/doc/latest/cassandra/new/java11.html documentation for additional details.
https://issues.apache.org/jira/browse/CASSANDRA-9608 has details.
After migrating to Java 8 you may see this error:
javax.servlet.ServletException: java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model
The XPathFactory.newInstance() method from Java8 with an older release of Saxon (< 9.5.1.5) on the classpath will cause this failure. To fix the issue you need to upgrade to a newer version of Saxon. The current version is 9.9 and is available in the Maven Repository and the Saxon website.
For more info on Java 8 for Google App Engine, see
Migrating to Java 8.
I have been using Neo4J 1.8.x as an embedded database in an application framework that breaks the regular ServiceLoader used by Neo4j. So far, I've worked around this issue by using the OSGi instructions for Neo4j. This has worked great.
However, these OSGi instructions no longer work for 1.9.0, 1.9.1 or 2.0.0-M03. When initializing the embedded database I get this exception:
java.lang.ExceptionInInitializerError
at plugins.fritter.Fritter.setupNeo4j(Fritter.java:240)
at plugins.fritter.Fritter.runPlugin(Fritter.java:106)
at freenet.pluginmanager.PluginHandler.startPlugin(PluginHandler.java:45)
at freenet.pluginmanager.PluginManager.realStartPlugin(PluginManager.java:394)
at freenet.pluginmanager.PluginManager.startPluginFile(PluginManager.java:367)
at freenet.clients.http.PproxyToadlet$3.run(PproxyToadlet.java:157)
at freenet.support.PooledExecutor$MyThread.innerRun(PooledExecutor.java:247)
at freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:187)
at freenet.support.io.NativeThread.run(NativeThread.java:129)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.neo4j.graphdb.factory.GraphDatabaseSettings.<clinit>(GraphDatabaseSettings.java:79)
... 9 more
I am aware that the OSGi setup instructions have changed from 1.9.0 and higher versions OSGI, but the new initialization methods do not address the issue.
Is neo4j > 1.8.3 still supported in a non-ServiceLoader / OSGi context and, if so, what is the proper way to set it up?
Getting this exception unable to find the reason why? Has anybody seen this before? I am running my application in WAS 8.0(beta version).
com.ibm.websphere.management.exception.DescriptorParseException: ADMN0001W: The service is unable to parse the MBean descriptor file
com/ahold/ers/dcr/common/jmx/mbeans/impl\SpringContextMBean.xml. at
com.ibm.ws.management.descriptor.MBeanDescriptorManager.loadDescriptorFile(MBeanDescriptorManager.java:411)
at
com.ibm.ws.management.descriptor.MBeanDescriptorManager.getDescriptor(MBeanDescriptorManager.java:190)
at
com.ibm.ws.management.MBeanFactoryImpl.activateMBean(MBeanFactoryImpl.java:458)
Caused by: java.io.FileNotFoundException: mbeans\AlertHibernateManagerMBean.xml
The forums on the net say i would need to change the JDK and point it to the one provided with WAS 8.0(beta version). Didn't understand this either. I am trying to migrate JavaEE 5 compliant code to WAS 8.0(beta version) (Java EE6). It should happen smoothly i guess as JVM is backward compatible. I hope i wouldn't need to recompile my code with Java EE6 just to make it work with WAS8. Is my understanding correct?
When I try to fill a JasperReport in my Servlet running on Websphere 6.1 I get an UnsupportedClassVersionError: Bad major version at offset=6.
I guess that the compiled JasperReport has a different version (java 6?) than the jre on websphere can execute (which would be java 5), but I can not figure out why. Compiling the reports with maven or in the application (in the servlet) both leads to the error.
According to the demo which was provided with JasperReports, which also shows how to use it with Java 1.5, I added following config to the jasperreports.properties:
org.eclipse.jdt.core.compiler.source=1.5
org.eclipse.jdt.core.compiler.compliance=1.5
org.eclipse.jdt.core.compiler.codegen.TargetPlatform=1.5
But the error still exists.
The language used in the report is Java, so which compiler is the correct one to use? net.sf.jasperreports.engine.design.JRJdtCompiler or net.sf.jasperreports.engine.design.JRJavacCompiler?
Unfortunately, the documentation does not explain the difference between those two compilers...
Edit: so fare I have been using the JRJavacCompiler. With the JRJdtCompiler I get a NullPointer Exception:
java.lang.NullPointerException
at java.lang.Class.isAssignableFrom(Native Method)
at net.sf.jasperreports.engine.fill.JRFillTextField.getFormat(JRFillTextField.java:706)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluateText(JRFillTextField.java:394)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluate(JRFillTextField.java:368)
at net.sf.jasperreports.engine.fill.JRFillElementContainer.evaluate(JRFillElementContainer.java:258)
at net.sf.jasperreports.engine.fill.JRFillBand.evaluate(JRFillBand.java:499)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2036)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:760)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:270)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:128)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:946)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:864)
at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:84)
at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:624)
at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:540)
at com.swissre.sod.jone.web.server.FileStreamingServlet.doGet(FileStreamingServlet.java:48)
It might be that you are using libraries in you application that are compiled in java 6.
You could check the MANIFEST information of your dependencies to find out more.