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.
Related
i have written a example for login using gwt tool with hibernate and spring integration.
getting this error-
Initializing App Engine server
SLF4J: The requested version 1.5.8 by your slf4j binding is not compatible with [1.6]
SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
Module setup completed in 579 ms
java.lang.AbstractMethodError: org.slf4j.impl.Log4jLoggerAdapter.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V
at org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:620)
at org.eclipse.jetty.util.log.JettyAwareLogger.debug(JettyAwareLogger.java:206)
at org.eclipse.jetty.util.log.Slf4jLog.debug(Slf4jLog.java:89)
at org.eclipse.jetty.util.component.Container.add(Container.java:206)
at org.eclipse.jetty.util.component.Container.update(Container.java:169)
at org.eclipse.jetty.util.component.Container.update(Container.java:111)
at org.eclipse.jetty.server.Server.setConnectors(Server.java:200)
at org.eclipse.jetty.server.Server.addConnector(Server.java:174)
at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:117)
at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:101)
at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:71)
at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:49)
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 com.google.gwt.dev.shell.SuperDevListener$1.run(SuperDevListener.java:112)
jars i have used these jars---------
thanks in advance
AbstractMethodError can only occur at run time if the definition of some class has incompatibly changed since the currently executing method was last compiled.
Seems like the slf4j-api version you have is higher than the slf4j binding version (such as slf4j-jdk14.jar or slf4j-log4j12.jar used to bind slf4j to an underlying logging framework).
For example - slf4j-api 1.7.6 along with slf4j-log4j12-1.5.8 will throw the same error.
You would need to syn the version of both slf4j apis and its binding jar verson.
Mostly its a libraries confilict, what that means there is a library uses log4j with version 1.5.8, and you have imported log4j 1.6.
2 things to try:
1- remove the log4j 1.6 from your imported jars.
2- replace log4j 1.6 jar file with log4j 1.5.8 jar file.
Hope that will help :)
I'm using the Amazon SQS connector in my Mule project. When I updated it from the 2.5.5 to the 3.0.0 version according to the user guide and set the DEBUG logging level for the com.amazonaws package I noticed the following error right after project starts:
DEBUG 2015-07-20 15:15:56,927 [Receiving Thread] com.amazonaws.1.9.39.shade.jmx.spi.SdkMBeanRegistry: Failed to load the JMX implementation module - JMX is disabled
java.lang.ClassNotFoundException: com.amazonaws.1.9.39.shade.jmx.SdkMBeanRegistrySupport
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 org.mule.module.launcher.FineGrainedControlClassLoader.findClass(FineGrainedControlClassLoader.java:175)
at org.mule.module.launcher.MuleApplicationClassLoader.findClass(MuleApplicationClassLoader.java:134)
at org.mule.module.launcher.FineGrainedControlClassLoader.loadClass(FineGrainedControlClassLoader.java:119)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at com.amazonaws.1.9.39.shade.jmx.spi.SdkMBeanRegistry$Factory.<clinit>(SdkMBeanRegistry.java:46)
at com.amazonaws.1.9.39.shade.metrics.AwsSdkMetrics.registerMetricAdminMBean(AwsSdkMetrics.java:351)
at com.amazonaws.1.9.39.shade.metrics.AwsSdkMetrics.<clinit>(AwsSdkMetrics.java:316)
at com.amazonaws.1.9.39.shade.AmazonWebServiceClient.requestMetricCollector(AmazonWebServiceClient.java:629)
at com.amazonaws.1.9.39.shade.AmazonWebServiceClient.isRMCEnabledAtClientOrSdkLevel(AmazonWebServiceClient.java:570)
at com.amazonaws.1.9.39.shade.AmazonWebServiceClient.isRequestMetricsEnabled(AmazonWebServiceClient.java:562)
at com.amazonaws.1.9.39.shade.AmazonWebServiceClient.createExecutionContext(AmazonWebServiceClient.java:523)
at com.amazonaws.1.9.39.shade.services.sqs.AmazonSQSClient.listQueues(AmazonSQSClient.java:1163)
at com.amazonaws.1.9.39.shade.services.sqs.AmazonSQSClient.listQueues(AmazonSQSClient.java:1501)
at org.mule.modules.sqs.connection.strategy.SQSConnectionManagement.connect(SQSConnectionManagement.java:173)
at org.mule.modules.sqs.connectivity.SQSConnectionManagementSQSConnectorAdapter.connect(SQSConnectionManagementSQSConnectorAdapter.java:21)
at org.mule.modules.sqs.connectivity.SQSConnectionManagementSQSConnectorAdapter.connect(SQSConnectionManagementSQSConnectorAdapter.java:9)
at org.mule.devkit.3.6.1.shade.connection.management.ConnectionManagementConnectorFactory.makeObject(ConnectionManagementConnectorFactory.java:47)
at org.mule.devkit.3.6.1.shade.connection.management.ConnectionManagementConnectorFactory.makeObject(ConnectionManagementConnectorFactory.java:15)
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
at org.mule.modules.sqs.connectivity.SQSConnectorConfigConnectionManagementConnectionManager.acquireConnection(SQSConnectorConfigConnectionManagementConnectionManager.java:407)
at org.mule.modules.sqs.connectivity.SQSConnectorConfigConnectionManagementConnectionManager.acquireConnection(SQSConnectorConfigConnectionManagementConnectionManager.java:55)
at org.mule.devkit.3.6.1.shade.connection.management.ConnectionManagementProcessInterceptor.execute(ConnectionManagementProcessInterceptor.java:47)
at org.mule.devkit.3.6.1.shade.connection.management.ConnectionManagementProcessInterceptor.execute(ConnectionManagementProcessInterceptor.java:19)
at org.mule.security.oauth.process.RetryProcessInterceptor.execute(RetryProcessInterceptor.java:84)
at org.mule.devkit.3.6.1.shade.connection.management.ConnectionManagementProcessTemplate.execute(ConnectionManagementProcessTemplate.java:33)
at org.mule.modules.sqs.sources.ReceiveMessagesMessageSource.run(ReceiveMessagesMessageSource.java:134)
at java.lang.Thread.run(Thread.java:662)
It's true, the mule-module-sqs-3.0.0.jar downloaded by Maven doesn't contain such class. I rebuild the Amazon SQS connector's source code with little changes in the pom.xml: set <minimizeJar>false</minimizeJar> for the maven-shade-plugin. Then the missing class appeared in the jar and I managed to run the project without errors.
Not sure is it a bug or not but don't like the idea to build the connector manually. Will really appreciate if you help me to sort it out. Thanks.
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 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.
I'm using spring's Jaxb2Marshaller (without web services) to unmarshal some xml. The xml code is code-gen via maven-jaxb-plugin, and I instantiate the Jaxb2Marshaller in spring via:
<bean id="unmarshaller" class="...Jaxb2Marshaller" p:contextPath="my.package.path" />
Then start with:
mvn clean package
mvn tomcat:run
The first unmarshaller is created fine, the second throws with org.springframework.oxm.jaxb.JaxbSystemException because it can't find ObjectFactory (which is generated by the maven-jaxb-plugin, and I've verified is in fact present in the jar, in the correct package).
I actually have two unmarshallers, (although I've tried with one unmarshaller and contextPath with colon separated package paths, with same results).
I don't think this is generally a problem with spring or my configuration, because if I deploy into a full tomcat container it works fine. I did notice that maven puts tomcat in my project/target/tomcat folder and there are some differences, such as there is no lib directory. I actually don't know what all the differences are between embedded tomcat and a regular installation.
Can someone explain:
1) exactly how embedded tomcat differs from a regular installation
2) if there are known limitations
3) if it can be configured to work properly in this situtation
Full stack trace:
SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'unmarshaller' defined in class path resource [spring.xml]: Invocation of init method failed; nested exception is org.springframework.oxm.jaxb.JaxbSystemException: "my.package.path" doesnt contain ObjectFactory.class or jaxb.index; nested exception is javax.xml.bind.JAXBException: "my.package.path" doesnt contain ObjectFactory.class or jaxb.index
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:380)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4135)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4630)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
at org.apache.catalina.startup.Embedded.start(Embedded.java:825)
at org.codehaus.mojo.tomcat.AbstractRunMojo.startContainer(AbstractRunMojo.java:558)
at org.codehaus.mojo.tomcat.AbstractRunMojo.execute(AbstractRunMojo.java:255)
For anyone else who runs across this, I eventually solved the problem by using classesToBeBound property instead of contextPath. The reason I had initially avoided classesToBeBound was that I thought I had to specify every single class in the model in the classesToBeBound list, which isn't the case. You simply specify the class that has the #XmlRootElement annotation.