CXF 2.6.1 Logging in jboss - exception

Question

I'm trying to upgrade cxf from version 2.3.1 to version 2.6.1 in my project.

The project is a web-application which uses cxf as a web-service consumer running in jboss 5.1

The project uses slf4j logging but the dependencies are provided since the jboss container comes with slf4j.

I created the following file in the project: META-INF/cxf/org.apache.cxf.Logger with a single line as its content: org.apache.cxf.common.logging.Slf4jLogger (As per cxf instructions)

When I run the project in jboss (stand-alone or from eclipse) I get the following error:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name '******' defined in class path resource [applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Factory method [public synchronized java.lang.Object org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create()] threw exception; nested exception is java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V
    at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:581)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1015)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:911)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:485)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
    at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
    at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383)
    at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
    at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
    at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
    at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
    at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
    at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
    at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
    at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
    at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
    at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
    at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)

It seems to have something to do with the logging but when I lookup the class of the slf4j-api provided by jboss I can see that the method is correct:

public abstract void log(Marker paramMarker, String paramString1, int paramInt, String paramString2, Throwable paramThrowable);

This exception keeps the application from starting.

I can confirm that slf4j was working since all the logs were written correctly.

I tried setting slf4j as compile in maven but this causes other issues. I do not know how to continue. Can someone help with this?

Have you tried adding slf4j-api as a dependency with runtime scope? — Nicola Musatti, Aug 10 '12 at 12:14
@Nicola, yes I have but this adds the dependency to the lib folder of the webapp. This creates a dependency clash with the version provided by jboss. — tom, Aug 10 '12 at 12:21
Still no complaints are logged, are they? I saw your other comment on adding slf4j-api and slf4j-log4j12. I expect you now see an error message about having two logging contexts; still this is more or less the way I have it working. — Nicola Musatti, Aug 10 '12 at 13:31
Yes there are complaints but I have checked the logging and everything seems to be working correctly at first glance. So I consider this complaint more of a whine. Though, due to this issue a lot more testing is needed than planned :(. — tom, Aug 10 '12 at 13:49
Read [this](http://www.slf4j.org/codes.html#multiple_bindings) before embarking in your testing :-) — Nicola Musatti, Aug 10 '12 at 17:01
I read that and got confused. In the server.log is says ERROR STDERR ... and on the site they talk about a warning. Last time I checked error != warning. I don't know if the error is supposed to be a warning or if their warning is supposed to be an error ...?!? Heh?!? — tom, Aug 10 '12 at 17:05

score 0 · Accepted Answer · answered Aug 10 '12 at 12:05

0

Have you found exactly this method signature org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker, java/lang/String, java/lang/String, java/lang/Object, java/lang/Throwable;) in your classpath ?. Probably jboss slf4j libs are somehow older than the ones expected to be used by fresh cxf. Also, check your classpath for libs collisions

answered Aug 10 '12 at 12:05

Jan

138
1
8

There is only one slf4j lib in the classpath and that is the one from the client folder in jboss. (This is version 1.5.6). The method I show in the question is the one that comes from this api. By the way, you missed the I in the signature. That is the int on position three. – tom Aug 10 '12 at 12:19
Well, it seems that adding slf4j-api-1.6.4 AND slf4j-log4j12-1.6.4 to the lib folder of the project fixes the issue. I don't quiet understand why because the version provided by jboss has the correct signatures. (Might be a classloader issue?) – tom Aug 10 '12 at 13:08
Apparently I have become blind. The signature in 1.6.* is different:`public abstract void log(Marker paramMarker, String paramString1, int paramInt, String paramString2, Object[] paramArrayOfObject, Throwable paramThrowable);` So the jboss version is too old. Thanks. – tom Aug 10 '12 at 13:31
I haven't missed the int arg. I just copied method signature from exception (wanted but not found) which is different than the ones found in jboss slf4j api :-). Libs provided by jboss don't fill the requirements ;-). Its rather 'missing libs' issue over classloader one – Jan Aug 10 '12 at 13:31

CXF 2.6.1 Logging in jboss - exception

1 Answers1