I am using the Apache HttpClient libs to handle my communication with an API. All of my code compiles and runs without error when I unit test the exploded code. However, when I JAR my source and test the code in a isolated integration test I get this error:
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logmanager/Logger$AttachmentKey
at org.slf4j.impl.Slf4jLoggerFactory.<clinit>(Slf4jLoggerFactory.java:31)
at org.slf4j.impl.StaticLoggerBinder.getLoggerFactory(StaticLoggerBinder.java:33)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:240)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:208)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:131)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:645)
at org.apache.http.impl.client.AbstractHttpClient.<init>(AbstractHttpClient.java:159)
at org.apache.http.impl.client.DefaultHttpClient.<init>(DefaultHttpClient.java:178)
at opart.api.client.trasnsport.Transport.get(Transport.java:81)
at opart.api.client.dao.objects.ObjectsDao.getInterestingObjects(ObjectsDao.java:70)
at opart.api.client.OpartApiClient.getInterestingObjects(OpartApiClient.java:79)
at ApiTest.interesting(ApiTest.java:32)
at ApiTest.main(ApiTest.java:21)
Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Logger$AttachmentKey
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
... 14 more
When I try to instantiate a DefaultHttpClient object thusly:
DefaultHttpClient defaultHttpClient = new DefaultHttpClient();
The libs I have included in my JAR are:
guava-r09.jar
commons-logging-1.1.1.jar
httpclient-4.1.2.jar
httpcore-4.1.2.jar
gson-1.7.1.jar
Any ideas as to why it is trying to reference JBoss?
The solution I found was to use the zipfileset ant target which safely explodes the contents of the JARchives inside the root of the uber JAR.
Related
I am getting following error while running JUnit5 with SpringBoot.
Here is the stack trace that I get when I run
./gradlew clean test
:junitPlatformTest
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/logging/log4j/util/ReflectionUtil
at org.apache.logging.log4j.jul.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:34)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at org.apache.logging.log4j.jul.LogManager.getLogger(LogManager.java:89)
at java.util.logging.LogManager.demandLogger(LogManager.java:551)
at java.util.logging.Logger.demandLogger(Logger.java:455)
at java.util.logging.Logger.getLogger(Logger.java:502)
at org.junit.platform.commons.logging.LoggerFactory$DelegatingLogger.<init>(LoggerFactory.java:62)
at org.junit.platform.commons.logging.LoggerFactory.getLogger(LoggerFactory.java:49)
at org.junit.platform.launcher.core.DefaultLauncher.<clinit>(DefaultLauncher.java:44)
at org.junit.platform.launcher.core.LauncherFactory.create(LauncherFactory.java:59)
at org.junit.platform.console.tasks.ConsoleTestExecutor.executeTests(ConsoleTestExecutor.java:61)
at org.junit.platform.console.tasks.ConsoleTestExecutor.lambda$execute$0(ConsoleTestExecutor.java:57)
at org.junit.platform.console.tasks.CustomContextClassLoaderExecutor.invoke(CustomContextClassLoaderExecutor.java:33)
at org.junit.platform.console.tasks.ConsoleTestExecutor.execute(ConsoleTestExecutor.java:57)
at org.junit.platform.console.ConsoleLauncher.executeTests(ConsoleLauncher.java:85)
at org.junit.platform.console.ConsoleLauncher.execute(ConsoleLauncher.java:75)
at org.junit.platform.console.ConsoleLauncher.execute(ConsoleLauncher.java:48)
at org.junit.platform.console.ConsoleLauncher.main(ConsoleLauncher.java:40)
Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.util.ReflectionUtil
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 18 more
The github url for above code is github link
This is caused by mixing different versions of Log4J on the test runtime classpath. Spring Boot pulls in 2.10.0, your build.gradle declares 2.6.2.
If you remove the version from your dependency definition, Spring Boot will define the version and it will work.
So, please replace these two lines
testRuntime("org.apache.logging.log4j:log4j-core:${log4jVersion}")
testRuntime("org.apache.logging.log4j:log4j-jul:${log4jVersion}")
with these:
testRuntime("org.apache.logging.log4j:log4j-core")
testRuntime("org.apache.logging.log4j:log4j-jul")
Alternatively, you can delete the logManager property from the junitPlatform extension and remove both dependencies.
I try to load the weblogic.jar of the weblogic server (12.1.3) into the classpath dynamically, e.g. via an UrlClassloader during runtime. Then I want to use this classloader to load and start the emebedded weblogic server via reflection (the reason is that we build our own custom test runner):
File file = new File("D:/Oracle/wls12130/wlserver/server/lib/weblogic.jar");
URL[] urls = new URL[]{file.toURI().toURL()};
URLClassLoader urlClassLoader = new URLClassLoader(urls, Thread.currentThread().getContextClassLoader());
Class<?> factoryClass = urlClassLoader.loadClass("weblogic.server.embed.EmbeddedServerFactory");
Class<?> serverClass = urlClassLoader.loadClass("weblogic.server.embed.EmbeddedServer");
Object factoryObject = factoryClass.newInstance();
Method factoryMethod = factoryClass.getDeclaredMethod("getEmbeddedServer");
Method serverMethod = serverClass.getDeclaredMethod("start");
Object server = factoryMethod.invoke(factoryObject);
serverMethod.invoke(server);
The code works only if I add the weblogic.jar manually (typically located in 'server/lib' directory of the weblogic server) to the classpath in the IDE (eclipse or intellij). However, it is supposed to load the classes via the urlclassloader without the weblogic.jar loaded as an external library in the IDE, which gives me the following exception:
weblogic.server.embed.EmbeddedServerException: Error creating default domain
at weblogic.server.embed.internal.DomainConfig.createConfig(DomainConfig.java:235)
at weblogic.server.embed.internal.DomainConfig.getDefaultDomain(DomainConfig.java:143)
at weblogic.server.embed.internal.DomainConfig.ensureInitialized(DomainConfig.java:66)
at weblogic.server.embed.internal.EmbeddedServerImpl.ensureStarted(EmbeddedServerImpl.java:213)
at weblogic.server.embed.internal.EmbeddedServerImpl.start(EmbeddedServerImpl.java:111)
... 10 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at weblogic.management.internal.CIEDomainGenerator.generateDefaultDomain(CIEDomainGenerator.java:62)
at weblogic.server.embed.internal.EmbeddedServerProvider.createDefaultDomain(EmbeddedServerProvider.java:142)
at weblogic.server.embed.internal.DomainConfig.createConfig(DomainConfig.java:233)
... 14 more
Caused by: com.oracle.cie.domain.DomainConfigException: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException
at com.oracle.cie.domain.DomainInfoHelper.createDefaultDomain(DomainInfoHelper.java:824)
at com.oracle.cie.domain.DomainInfoHelper.createDefaultDomain(DomainInfoHelper.java:705)
... 21 more
What am I doing wrong here?
I am trying to redirect Java Util Logging logs to Log4j 2.1 using the birdge provided log4j-jul-2.1, but stuck with classpath problems. I have all the log4j jars in the domains lib directory and used the following JVM parameter as mentioned in log4j documentation:
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
The problem is that the bridge LogManager provided by log4j is not available in Glassfish AppClassLoader during startup and it causes the exception below. I can fix that by modifying server main classpath (provided by -cp argument), but this is bad. Is there any other/better looking way to achieve that? Simply putting it into server main lib directory does not also work as its again not AppClassLoader.
Could not load Logmanager "org.apache.logging.log4j.jul.LogManager"
java.lang.ClassNotFoundException: org.apache.logging.log4j.jul.LogManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.util.logging.LogManager$1.run(LogManager.java:167)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.<clinit>(LogManager.java:157)
at java.util.logging.Logger.getLogger(Logger.java:287)
at com.sun.enterprise.glassfish.bootstrap.ASMainHelper.<clinit>(ASMainHelper.java:67)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)
I finally decided to use SLF4J and its SLF4JBridgeHandler for handling Java Util Logging calls. The main benefit of it is that it can be initialized at some later point when all the classes are loaded and after all required static initializations.
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();
I also switched to Logback as a backend as with this solution Log4j encounters performance problems for disable JUL loggers.
I created a web-service app based on Apache CXF (2.7.5), deployed it on a Glassfish 3.0.1 and it works fine till I turn on WS-Sec support. Then I get the following exception when I try to do a web-service request:
Caused by: javax.xml.crypto.NoSuchMechanismException: class configured for XMLSignatureFactory(provider: ApacheXMLDSig)cannot be found.
at javax.xml.crypto.dsig.XMLDSigSecurity.doGetImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLSignatureFactory.findInstance(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLSignatureFactory.getInstance(Unknown Source) ~[webservices-osgi.jar:1.0]
at org.apache.ws.security.message.WSSecSignature.init(WSSecSignature.java:127) ~[wss4j-1.6.10.jar:1.6.10]
at org.apache.ws.security.message.WSSecSignature.<init>(WSSecSignature.java:120) ~[wss4j-1.6.10.jar:1.6.10]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1730) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:546) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:147) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
... 273 common frames omitted
Caused by: java.lang.ClassNotFoundException: org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) ~[felix.jar:na]
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) ~[felix.jar:na]
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) ~[felix.jar:na]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_43]
It seems that CXF invokes the XMLSignatureFactory class contained by Glassfish's default webservice provider implementation instead of invoking it's own one (it's in the xmlsec.jar file). All CXF files are packed into my war file and also have the <class-loader delegate="false" /> set in sun-web.xml.
Can someone help me why the Glassfish classloader works this way and how could I fix this?
I managed to find out that Glassfish (at least the 3.0.1 version) modifies the default class loading behavior to "protect" some packages (mostly javax. packages) in it's classpath. That's the reason why it finds and uses classes in it's modules directory instead of the one in my war's lib.
To solve this a JVM option should be added to the domain.xml:
<jvm-options>-Dcom.sun.enterprise.overrideablejavaxpackages=javax.xml.crypto,javax.xml.crypto.dsig</jvm-options>
With this Glassfish will allow to use your libs in your war file. But even with this setting it's problematic to use CXF with WS-Securityy along with Metro. The better solution is to use a Glassfish with only Web Profile not Full Profile as Web Profile doesn't have Metro included.
I am getting the following exception when I access the web service from my Axis2 generated stub client.
Can anyone put some light one it?
Thanks.
Caused by: org.apache.axis2.AxisFault: Unable to access unsupported property javax.xml.stream.supportDTD
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:123)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:417)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at amdocs.cl.utils.CollectionsServiceStub.GetEquipmentInfo(CollectionsServiceStub.java:267)
at amdocs.cl.utils.DDPCollectionConnectorUtils.getEquipmentInfo(DDPCollectionConnectorUtils.java:162)
... 7 more
Caused by: java.lang.IllegalArgumentException: Unable to access unsupported property javax.xml.stream.supportDTD
at weblogic.xml.stax.ConfigurationContextBase.check(ConfigurationContextBase.java:60)
at weblogic.xml.stax.ConfigurationContextBase.setProperty(ConfigurationContextBase.java:54)
at weblogic.xml.stax.XMLStreamInputFactory.setProperty(XMLStreamInputFactory.java:280)
at org.apache.axiom.util.stax.dialect.StAXDialectUtils.disallowDoctypeDecl(StAXDialectUtils.java:40)
at org.apache.axiom.util.stax.dialect.UnknownStAXDialect.disallowDoctypeDecl(UnknownStAXDialect.java:39)
at org.apache.axiom.om.util.StAXParserConfiguration$4.configure(StAXParserConfiguration.java:116)
at org.apache.axiom.om.util.StAXUtils$7.run(StAXUtils.java:520)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.axiom.om.util.StAXUtils.newXMLInputFactory(StAXUtils.java:495)
at org.apache.axiom.om.util.StAXUtils.getXMLInputFactory_perClassLoader(StAXUtils.java:566)
at org.apache.axiom.om.util.StAXUtils.getXMLInputFactory(StAXUtils.java:172)
at org.apache.axiom.om.util.StAXUtils.getXMLInputFactory(StAXUtils.java:137)
at org.apache.axiom.om.util.StAXUtils.createXMLStreamReader(StAXUtils.java:196)
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:64)
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:197)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108)
I too had the same issue and finally found that the problem is with incorrect context config.
Axis2 configuration context is being created with weblogic.jar file instead of axis2 jar, so change the build class path order. First point all the axis2 jars and atlast point the weblogic.jar in class path.
I resolved this by adding jax-rt jar in my classPath.
Or Add below dependency in your pom
<depepdency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.2.10</version>
</dependency>