I´ve deployed an EAR on a Websphere Application Server 7. In my code there is a part where I try to unmarshall a XML file into an object. I get this error when trying to do that:
java.lang.NoClassDefFoundError: com.ibm.xtq.bcel.util.SyntheticRepository (initialization failure)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:140)
at com.ibm.xtq.bcel.classfile.JavaClass.<init>(JavaClass.java:109)
at com.ibm.xtq.bcel.classfile.JavaClass.<init>(JavaClass.java:228)
at com.ibm.xtq.bcel.generic.ClassGen.getJavaClass(ClassGen.java:174)
at com.ibm.fcg.bcel.FcgClassGenBCEL.dump2(Unknown Source)
at com.ibm.fcg.bcel.FcgClassGenBCEL.dump(Unknown Source)
at com.ibm.xml.xlxp2.jaxb.unmarshal.codegen.fcg.FCGDeserializationStubGenerator.generate(FCGDeserializationStubGenerator.java:249)
at com.ibm.xml.xlxp2.jaxb.codegen.AbstractGeneratedStubFactory.generateByteCode(AbstractGeneratedStubFactory.java:96)
at com.ibm.xml.xlxp2.jaxb.unmarshal.codegen.fcg.FCGStubFactory.generateStubByteCode(FCGStubFactory.java:46)
at com.ibm.xml.xlxp2.jaxb.codegen.AbstractGeneratedStubFactory.getStubClassConstructor(AbstractGeneratedStubFactory.java:154)
at com.ibm.xml.xlxp2.jaxb.unmarshal.codegen.AbstractGeneratedDeserializationStubFactory.createStub(AbstractGeneratedDeserializationStubFactory.java:58)
at com.ibm.xml.xlxp2.jaxb.unmarshal.impl.DeserializationContext.startComplexType(DeserializationContext.java:662)
at com.ibm.xml.xlxp2.jaxb.unmarshal.impl.DeserializationContext.handleRootElementEvent(DeserializationContext.java:303)
at com.ibm.xml.xlxp2.jaxb.unmarshal.impl.JAXBDocumentScanner.produceRootElementEvent(JAXBDocumentScanner.java:186)
at com.ibm.xml.xlxp2.scan.DocumentScanner.scanRootElement(DocumentScanner.java:2234)
at com.ibm.xml.xlxp2.scan.DocumentScanner.scanProlog(DocumentScanner.java:1726)
at com.ibm.xml.xlxp2.scan.DocumentScanner.nextEvent(DocumentScanner.java:1316)
at com.ibm.xml.xlxp2.scan.DocumentScanner.parseDocumentEntity(DocumentScanner.java:1168)
at com.ibm.xml.xlxp2.jaxb.unmarshal.impl.JAXBDocumentScanner.unmarshal(JAXBDocumentScanner.java:125)
at com.ibm.xml.xlxp2.jaxb.unmarshal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:120)
at com.inditex.lois.core.ws.utilidades.services.impl.AdaptadorServiceImpl.transformarXMLenObjeto(AdaptadorServiceImpl.java:137)
As far as I know that class is part of IBM JDK and cannot be found in runtime. Is there anything I have to modify in my ear or, as I guess, its all about configuring/modifiying WAS configuration (or even applying a patch if this is a bug).
Any help? Thanks a lot.
(Sorry for my english :) )
This exception means that the class com.ibm.xtq.bcel.util.SyntheticRepository is found, but failed static initialization. If there is no other message in the log about this, then this is the time to open a PMR with IBM. Static initializers in internal WebSphere code should never fail during normal usage course.
Same here, there is an APAR:
http://www-01.ibm.com/support/docview.wss?uid=swg1IV41639
Problem conclusion
This defect will be fixed in:
6.0.0 SR14
6.0.1 SR6
7.0.0 SR5
.
The fix resolved the AccessControlException. SyntheticRepository
class can be initialized properly, hence NoClassDefFoundError
does not occur.
Related
When org.apache.myfaces.CACHE_EL_EXPRESSIONS with value alwaysRecompile is in web.xml, WAR starts but when trying to go to any JSF view, this exception is thrown:
java.lang.NoSuchMethodException: org.apache.myfaces.view.facelets.AbstractFaceletCache.setMemberFactories(javax.faces.view.facelets.FaceletCache$MemberFactory, javax.faces.view.facelets.FaceletCache$MemberFactory)
Any ideas? WebSphere 9 is using MyFaces 2.2. Are there some limitations as compared to "usual" MyFaces 2.2 implementation?
I tested on 9.0.5.6 and also encountered the same error.
java.lang.NoSuchMethodException: org.apache.myfaces.view.facelets.AbstractFaceletCache.setMemberFactories(javax.faces.view.facelets.FaceletCache$MemberFactory, javax.faces.view.facelets.FaceletCache$MemberFactory)
at java.lang.Class.newNoSuchMethodException(Class.java:567)
at java.lang.Class.throwExceptionOrReturnNull(Class.java:1222)
at java.lang.Class.getMethodHelper(Class.java:1308)
at java.lang.Class.getDeclaredMethod(Class.java:936)
at org.apache.myfaces.view.facelets.impl.DefaultFaceletFactory.<init>(DefaultFaceletFactory.java:166)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.createFaceletFactory(FaceletViewDeclarationLanguage.java:2233)
I see the code is trying to retrieve the setMemberFactories method with 2 args rather than 3 (as the exception indicates, too).
I'll create an issue and have this issue resolve in the next WAS 9 release cycle. Thanks for discovering this!
My context :
BND (bndtools with Eclipse IDE) ;
OSGI (-runfw: org.eclipse.osgi;version='[3.16.100.v20201030-1916,3.16.200.v20210226-1447]') ;
runee: JavaSE-1.8
in bnd.launch file :
-runbundles: \
org.apache.felix.gogo.command;version='[1.1.2,1.1.3)',\
org.apache.felix.gogo.runtime;version='[1.1.4,1.1.5)',\
org.apache.felix.gogo.shell;version='[1.1.4,1.1.5)',\
org.apache.commons.commons-fileupload;version='[1.4.0,1.4.1)',\
org.apache.commons.commons-io;version='[2.8.0,2.8.1)',\
org.apache.felix.webconsole;version='[4.6.0,4.6.1)',\
org.apache.felix.http.jetty;version='[4.1.6,4.1.7)',\
org.apache.felix.http.servlet-api;version='[1.1.2,1.1.3)',\
org.apache.felix.scr;version='[2.1.24,2.1.25)',\
org.eclipse.equinox.cm;version='[1.5.0,1.5.1)',\
org.eclipse.equinox.console;version='[1.4.300,1.4.301)',\
org.eclipse.equinox.device;version='[1.1.100,1.1.101)',\
org.eclipse.osgi.services;version='[3.10.0,3.10.1)',\
org.eclipse.osgi.util;version='[3.6.0,3.6.1)',\
ch.qos.logback.classic;version='[1.2.3,1.2.4)',\
ch.qos.logback.core;version='[1.2.3,1.2.4)',\
org.apache.felix.logback;version='[1.0.2,1.0.3)',\
slf4j.api;version='[1.7.30,1.7.31)',\
com.sun.activation.jakarta.activation;version='[2.0.1,2.0.2)',\
jakarta.xml.bind-api;version='[3.0.1,3.0.2)',\
com.sun.xml.bind.jaxb-osgi;version='[3.0.1,3.0.2)'
No use of any POM.xml file at all
When I launch the application, I get a
jakarta.xml.bind.JAXBException: Implementation of Jakarta XML Binding-API has not been found on module path or classpath.
- with linked exception:
[java.lang.ClassNotFoundException: org.glassfish.jaxb.runtime.v2.ContextFactory]
at jakarta.xml.bind.ContextFinder.newInstance(ContextFinder.java:255)
at jakarta.xml.bind.ContextFinder.newInstance(ContextFinder.java:243)
at jakarta.xml.bind.ContextFinder.find(ContextFinder.java:407)
at jakarta.xml.bind.JAXBContext.newInstance(JAXBContext.java:691)
at jakarta.xml.bind.JAXBContext.newInstance(JAXBContext.java:632)
If I add org.glassfish.jaxb.runtime;version='[3.0.1,3.0.2)'
to the runbundles list, it doesn't change anything (same exception).
Then if I add -runpath: org.glassfish.jaxb.runtime;version='[3.0.1,3.0.2)' to the bnd.launch file : it doesn't change anything either (same exception).
What did I did wrong ??
Thanks
Are you running on Java 1.9 or later? (The error message talks about module path.) The problem might be that JAXB is no longer exported from the JVM in later versions. This will the class loading of glassfish to fail without telling the underlying reason sometimes.
You can add -runvm -v:class to get more information about the class loading.
I am trying to add tests using latest (5.7.0) Mockito and using Mockito.mockStatic(...)
to mock class with static methods which works fine . However when I have class with static block it is unable to create mock and fais with java.lang.InternalError: class redefinition failed: invalid class .
Is this supported in latest mockito versions or still I have to live with other alternatives like powermock.
I did face the same error and couldn't find answer in the internet, so I see that it is 1 month old question but might help someone.
The problem was that mocked class (or classes that this static block used) was not in the classpath. Before you can mock the method all static blocks or fields initializators will be run, and it causes the problem.
You can verify what class is missing in your classpath by simply trying to use this static method before mocking it. You should get java.lang.NoClassDefFoundError with a class name.
When you resolve this problem, everything should work.
I had this issue, and for me it was due to an Error being thrown from instrumentation.retransformClasses called from org.mockito.internal.creation.bytebuddy.inlineBytecodeGenerator. Somewhere between there and findOrInsert in net.bytebuddy.TypeCache, the Throwable looses its context (for mockito-core 4.1.0 and bytebuddy 1.12.0)
In my case, the error being thrown was a NoClassDefFoundError for Jetty Servlet. This ultimately turned out to be a dodgy local build of a different maven module I had been working on, so clearing out my ~/.m2 and downloading a legit version fixed that right up.
You might be able to catch the Error being thrown in inlineBytecodeGenerator and taking a look at what's really going on, if this is in fact the same problem.
Trying to construct a Hazelcast 4.1 client configuration from XML throws IllegalArgumentException if the application is running in Apache TomEE-Plus 8.0.0.
If executed in a standalone Java VM (AdoptOpenJDK 11.0.5), the problem does not occur.
Standalone test and TomEE use identical JDK.
Part of the stack trace:
java.lang.IllegalArgumentException: Nicht unterstützt: http://javax.xml.XMLConstants/property/accessExternalDTD
at org.apache.xalan.processor.TransformerFactoryImpl.setAttribute(TransformerFactoryImpl.java:571)
at com.hazelcast.config.AbstractXmlConfigHelper.schemaValidation(AbstractXmlConfigHelper.java:109)
at com.hazelcast.client.config.XmlClientConfigBuilder.parseAndBuildConfig(XmlClientConfigBuilder.java:175)
at com.hazelcast.client.config.XmlClientConfigBuilder.build(XmlClientConfigBuilder.java:157)
at com.hazelcast.client.config.XmlClientConfigBuilder.build(XmlClientConfigBuilder.java:150)
at com.hazelcast.client.config.XmlClientConfigBuilder.build(XmlClientConfigBuilder.java:145)
...
I found a post on StackOverflow that seems to be related to my problem:
Set feature accessExternalDTD in TransformerFactory
Unfortunately, I have no idea if the suggested solution in answer no. 1 really matches my problem.
And even if so, I do not know how to apply the suggested solution in application code or configurations only, without changes inside Hazelcast code.
Any ideas how to fix this?
Hazelcast Client-Config XML:
<?xml version="1.0" encoding="UTF-8"?>
<hazelcast-client xsi:schemaLocation="http://www.hazelcast.com/schema/client-config hazelcast-client-config-4.1.xsd"
xmlns="http://www.hazelcast.com/schema/client-config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
</hazelcast-client>
TomEE version:
apache-tomee-plus-8.0.0 (Apache Tomcat Version 9.0.22)
Java version:
AdoptOpenJDK 11.0.5
IMPLEMENTOR="AdoptOpenJDK"
IMPLEMENTOR_VERSION="AdoptOpenJDK"
JAVA_VERSION="11.0.5"
JAVA_VERSION_DATE="2019-10-15"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.charsets jdk.crypto.ec jdk.crypto.cryptoki jdk.dynalink jdk.httpserver jdk.internal.ed jdk.internal.le jdk.internal.vm.compiler.management jdk.jdwp.agent jdk.jfr jdk.jsobject jdk.localedata jdk.management.agent jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Linux"
SOURCE=".:git:7d14fe4b6f30"
This looks like this issue which is due to the presence of an old JAXP implementation in the classpath. This is fixed in Hazelcast 4.1.1 (fix pull request) by supplying a system property switch to avoid failing when XXE protection cannot be turned on.
You should be able to start your Hazelcast client in Apache TomEE by upgrading to Hazelcast 4.1.1 and setting system property hazelcast.ignoreXxeProtectionFailures=true (for example by supplying -Dhazelcast.ignoreXxeProtectionFailures=true to Apache TomEE's java startup command line).
This seems to be an issue with XML / DTD . Please check with the following config file
https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/resources/hazelcast-client-default.xml
and code
public ClientConfig clientConfig() throws Exception {
return new XmlClientConfigBuilder("hazelcast-client.xml").build();
}
I'm sure I'm missing something, but I'm not seeing it at all.
I'm creating PDFs using iText, and I want to do this in a bean. I've created one, but it's been erroring out. It seems some of the ways I've usually worked in Java don't seem to work in this bean.
For example, this line:
com.itextpdf.text.Document document1 = new com.itextpdf.text.Document();
will throw the error java.lang.NoClassDefFoundError: com.itextpdf.text.Document, even though the jar is imported, in the build path and com.itextpdf.text.Document is imported in the bean.
if you change it to this:
com.itextpdf.text.Document document1;
or
com.itextpdf.text.Document document1 = null;
the error goes away. I don't understand why one way works and the other doesn't, but it's a fairly easy change to make.
Now I need to set the page size. This will work in Eclipse:
document1.setPageSize(PageSize.LETTER);
but this is the error I get:
java.lang.NoClassDefFoundError: com.itextpdf.text.PageSize
Which might be because I've set it to null to initialize it. But
document1 = new Document();
and
document1 = new com.itextpdf.text.Document();
both throw java.lang.NoClassDefFoundError: com.itextpdf.text.Document
Oddly, the import statement for (iText) Document warns me it is never used.
document1.open();
will give the error java.lang.NoClassDefFoundError: com.itextpdf.text.Document as well.
So, am I missing something in the syntax in beans? I've created Notes Java agents, XAgents, and straight up Java Eclipse projects that work, but I can't get the methods to work in a 8.5.3 Java Bean. I imported the iText jars into WebContent\WEB-INF\lib and then added those (via add jars, not add external jars) to the build path. I've gotten the latest jars and I'm using them, I've built and cleaned, the bean is in faces-config. But I'm doing something wrong, and I can't see it.
If someone could point me in the right direction, I would be very grateful.
Cheers,
Brian
EDIT:
The license isn't a problem, but I still can't get the class to load even using the classLoader:
Thread currentThread = Thread.currentThread();
ClassLoader clCurrent = currentThread.getContextClassLoader();
//ClassLoader clCurrent=com.ibm.domino.xsp.module.nsf.NotesContext.getCurrent().getModule().getModuleClassLoader();
try {
currentThread.setContextClassLoader(Activator.class.getClassLoader());
DebugToolbar.get().info("after setting up FileOutputStream");
com.itextpdf.text.Document document1 = new com.itextpdf.text.Document();
//com.itextpdf.text.Document document1;
//com.itextpdf.text.Document document1 = null;
//document1 = new com.itextpdf.text.Document();
//document1.open();
document1.setPageSize(PageSize.LETTER);
I still get java.lang.NoClassDefFoundError: com.itextpdf.text.Document
I've cut the beans out, cleaned, built, pasted back in, cleaned built, still the error.
I appreciate the assistance.
Brian
Most likely you have a classloader isssue. Unless your app is strictly for internal use, you might reconsider use of iText since it is GPL. Apache PDFBox is an Apache licensed alternative (I'm particularly fond of) or Apache FOP (I'll complete the ]2 missing articles](http://www.wissel.net/blog/htdocs/DominoXSLT), promise). Of course OpenNTF's POI4XPages might just be what you need.
I called Lotus/ICS support. It seems for 8.5.3, if you put the jars in ~Lotus\Notes\jvm\lib\ext they will load. I'm testing this on my local, but the same path should work on the server. I'll test that Monday. I had researched, and if that is mentioned I didn't find it. Jars will be a design element in 9, putting them in a directory like this should not be needed for that version, but it seems that adding them this way is more consistent now. The jars have loaded properly for some applications I've made, so this confused me a bit.
Stephan and Panu, thank you for responding.
Brian