I get this message :
javax.xml.parsers.FactoryConfigurationError:
Provider
org.apache.xerces.jaxp.DocumentBuilderFactoryImp
but i can't seem to solve the problem. I have googled, but can't find any good solutions.
Does anyone have an idea of what could be wrong?
And maybe how to solve it :)
The org.apache.xerces is from the Apache Xerces package, and something in your application has a dependency on it. Try downloading it (latest version is 2.9.0) and adding it to your application's classpath.
DocumentBuilderFactory has a multi-step process for finding the actual parser implementation, as described in the linked JavaDoc. Your error message is almost certainly coming from there.
I suspect that your JBoss startup script is setting the javax.xml.parsers.DocumentBuilderFactory system property incorrectly (I've seen this happen before, used to avoid a bug in the released library). I would start by grepping the JBoss configuration directory for that property, followed by explicitly setting the jaxp.debug property (also described in the link). Assuming that your startup script is indeed explicitly setting the property, find out who made that change and ask him/her if you can delete it (or to provide you with the correct JARs if not).
As you've tagged your question JBoss, I'll assume your code is running in the JBoss container.
JBoss may have already loaded a version of Xerces for it's own use and you're trying to load a different version in your code (either explicitly or through some dependency) and the configuration for your version is not compatible with the version that's already loaded.
This JIRA Ticket on JBoss.org suggests deleting the xercesimpl.jar in jasperserver/WEB-INF/lib folder to allow your version to be used.
Related
This problem is duplicate to similar problems in Jetty, but I could not find literature about Websphere
https://github.com/eclipse/jetty.project/issues/1797
Error scanning entry "module-info.class" when starting Jetty server
I have a Websphere 8.5.5.7 running over Java 7. Only today we discovered that upgrading log4j from 2.7 to 2.10 breaks the startup. Following is one of the many stack traces:
[01/03/18 10.12.14:154 CET] 000003d9 ecs W com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl scanJAR unable to open input stream for resource module-info.class in archive WEB-INF/lib/log4j-api-2.10.0.jar
java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at com.ibm.ws.ecs.internal.scan.impl.ClassScanner.scanInputStream(ClassScanner.java:147)
at com.ibm.ws.ecs.internal.scan.impl.ClassScanner.scanInputStream(ClassScanner.java:124)
at com.ibm.ws.ecs.internal.scan.impl.ClassScanner.scanInputStream(ClassScanner.java:120)
at com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl.scanJAR(ScannerContextImpl.java:275)
at com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl.scanJARs(ScannerContextImpl.java:315)
at com.ibm.ws.ecs.internal.scan.context.impl.WARScannerContext.scanInternal(WARScannerContext.java:76)
at com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl.scan(ScannerContextImpl.java:87)
at com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl.getScannedClasses(ScannerContextImpl.java:70)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.scanForHandlesTypesClasses(WebAppImpl.java:760)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initializeServletContainerInitializers(WebAppImpl.java:601)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:406)
Basically the log4j developers had the great (but unlucky) idea of using multi-release jars for Java 9 to accommodate older Java runtimes.
Our installation cannot be upgraded. Those are the versions and we must keep them. I have tried to google around for multirelease jars with websphere but there seems to be no literature.
I would like to ask if there is any configuration workaround to disable massive scanning of jars at least in selected packages in the targeted version of websphere.
There is an existing APAR for this. See APAR PI89708.
If that does not fix the problem, you should open a PMR so that IBM can fix it.
WebSphere Application Server traditional does provide a mechanism to reduce the amount of scanning of JAR files. However, that might (or might not) be a workaround for this problem, since not all components of WAS respect the annotation scanning filters. Though it is still worth looking at since reducing the scanning activity can improve deployment time.
Take a look at the amm.filter.properties file under WAS_HOME/properties.
Add names of JAR files that you do not want scanned to the "Ignore-Scanning-Archives" property. There are more options for specifying JARs to be filtered from scanning. You can find more information here.
Also note that WAS 8.5.5 was released before multi-release JARs existed. So the support, or more accurately tolerance, has to be added in service. I say tolerance, because Java 9 is not supported at this time. For now, WAS simply has to tolerate the existence of classes under the META-INF directory.
If you absolutely cannot upgrade or patch the application server, then the simplest option is to modify the log4J JAR file, removing the classes under the META-INF directory. I know that is not desirable either, since you shouldn't have to modify a third-party JAR, but I have doubts that the filter will work in this case. So, without patching the application server, it might be the only option.
As you pointed out in your comment, in this particular case, since LOG4J does not have JAVA EE annotations, the warning message can be ignored. The application should start and function normally. If however, the JAR contained Java EE annotations, then those annotations would not have been processed. If that were the case, I would expect the application to start, but it might not function correctly.
>
Additional APARs were added since the original answer to this question. Here is the complete list of APARs:
PI89708, PI93744, PI96826, PH02014, PH03710.
I have a huge web application that I have to support. Recently when I downloaded the latest source from SVN and try to run it locally on Tomcat 6, I get the following error from one of the background batch jobs that the application runs...
2014-12-23 18:08:27 [taskScheduler-4] TaskUtils$LoggingErrorHandler [ERROR] Unexpected error occurred in scheduled task.
java.lang.NoSuchMethodError: javax.xml.stream.XMLEventFactory.newFactory()Ljavax/xml/stream/XMLEventFactory;
at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor$HeadersProcessor.<clinit>(ReadHeadersInterceptor.java:275)
So I believe the problem is the Apache class ReadHeadersInterceptor which my application's code calls is trying to call the newFactory() method from XMLEventFactory but is not finding that method, probably because it is reading an older version of XMLEventFactory.
I think this is happening because there are some JARs in my lib folder I need to remove or add. Problem is I don't know which one. I see there are several JARs which have XMLEventFactory including..
woodstox-core-asl-4.2.0
stax2-api-3.1.1
And it is also part of Java 6 in the rt.jar.
So out of all these Jars which one is it trying to read and not find that method it needs?
Thanks.
This is a problem with specific version of JDK/JRE 1.6 (I mean the update). It may looks weird but the JDK API change for specific major version.
Please take a loot at the following link. You can see there that with change from version 1.6.0.17 to 1.6.0.18 the new methods have been added on the XMLEventFactory class.
Probably you have the JRE version less thank 1.6.0.18. I've had the same problem with Apache CXF and dynamic proxies. The update of JRE 1.6.0.14 to 1.6.0.19 fixed the issue.
I hope it helps.
I have a requirement to create a word document. So I am trying to use docx4j. I get a runtime error.
java.lang.NoClassDefFoundError: org.docx4j.openpackaging.packages.WordprocessingMLPackage
I am sure I have docx4j3.0.1 and all the dependencies added to my build path.
Is there an issue with the class initialization mechanism?
Any ideas?
Had to add all the jars to the MQSI/shared-classes folder. That worked.
For future reference a good way to resolve these problems on IBM JRE platforms is to set the environment variable IBM_JAVA_OPTIONS=-Dibm.cl.verbose=* and restart the Broker.
This will cause classloading trace to be written to Broker's standard output (located in $MQSI_WORKPATH/components//
This shows you what jars are available in each classloader and which classloaders are being searched whenever a class is loaded.
I'm trying to write some Java which allows me to clear cache, but is there a problem where I use CacheManager.getInstance()... the error is:
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
When I add commons-logging-1.1.3.jar to the project the error is:
net.sf.ehcache.config.ConfigurationFactory parseConfiguration
WARNING: No configuration found. Configuring ehcache from
ehcache-failsafe.xml found in the classpath:
jar:file:/C:/Users/olawzi/Downloads/ehcache-1.2.3.jar!/ehcache-failsafe.xml
You solved the first issue correctly, by adding its dependency commons-logging.
The second one is, as stated, a warning and not an error (but nevertheless, I'd consider it a very serious warning, as the used defaults are quite probably not good for your application). It means that you forgot to add ehcache.xml, ehcache's configuration file, to the classpath. Add that file and the message will go away.
Also note that the ehcache version you seem to be using (1.2.3) is very old, it was released in 2006. The current version is 2.7, and it can be downloaded here. Instructions for Maven based projects are also on that page.
you should use maven or gradle to manages jar dependencies: it will bring the good version of all jars: otherwise your problem will be hard to fix
I've a chunk of code that works fine in isolation, but used a dependency in a clients project fails. A call to
Document doc = impl.createDocument(null,null,null);
fails (looks like the problem at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4913257). The instance of 'impl' in my unit tests is an instance of com.sun.org.apache.xerces.internal.dom.DOMImplementationImpl. In my clients code, its an instance of org.apache.xerces.dom.DOMImplementationImpl.
How do I trace back this dependency? I've tried manually going through all classes and jar files in the classpath, but cannot find the provider of org.apache.xerces.dom.DOMImplementation. Is is possible to observe when classes are loaded (and why)? How is the particular DOM implementation selected? Can I for now force the jvm to use a particular implementation?
The implementation in the "com.sun.org.apache..." package is the Xerces that's packaged as part of the JRE. The one starting "org.apache..." is the standalone distribution from Apache. They can be run together in the same application, but it can get quite confusing.
Your client's project would appear to contain a copy of the standalone apache distribution (probably xercesImpl.jar). Ask them to rem,ove it and see if it starts using the built-in JRE code.
Most likely you do not have xercesImpl.jar in the client project's classpath
I think you could deal with endorsed standards stuff.