jcl-over-slf4j is not a binding, it's an adapter. It implements the Apache Jakarta Commons Logging API, but instead of using the JCL to route log messages, it uses the installed SLF4j binding. But, it is true that the different SLF4j jars be of compatible versions. I think the actual problem that you are running into is that you have specifically included a runtime binding jar, but you didn't mention whether you also explicitly include the slf4j-api jar as a compile time dependency. If you didn't it will include the highest one explicitly included, which is the one specified by the ant.jar.
If I were you I would absolutely include the slf4j-api compile dependency, and probably the jcl-over-slf4j runtime dependency using the same version as your binding. (*Chris*) On Thu, May 7, 2015 at 12:04 AM, Strachan, Paul < [email protected]> wrote: > Hi, > > > > I’m creating a Groovy/JavaFX app which invokes an ant build script from a 3 > rd party software product installed on the same host. My app (Griffon) > has a runtime dependency of slf4j-log4j12-1.7.10. I’ve also added > ant-1.9.4 as a compile dependency. > > > > The ant build file imports other build scripts (from the 3rd party > “scripts” folder) which import others and eventually the necessary taskdef > and classpath refs are created – this classpath uses an older slf4j > implantation containing: jcl-over-slf4j-1.5.2.jar, slf4j-log4j12-1.5.2.jar, > slf4j-api-1.5.2.jar > > > > At runtime when I execute the target I’m seeing the following error and > the ant task did not complete: > > *def *antProject = *new *Project() > antProject.init() > ProjectHelper.*configureProject*(antProject, buildFile) > > antProject.executeTarget(*'*export*'*) > > > > Caused by: java.lang.NoSuchMethodError: > org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V > > at > org.apache.commons.logging.impl.SLF4JLocationAwareLog.warn(SLF4JLocationAwareLog.java:173) > > at > org.apache.axis2.util.Loader.getResourceAsStream(Loader.java:140) > > at > org.apache.axis2.deployment.FileSystemConfigurator.getAxisConfiguration(FileSystemConfigurator.java:113) > > at > org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:68) > > at > org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContextFromFileSystem(ConfigurationContextFactory.java:184) > > at > org.apache.axis2.client.ServiceClient.configureServiceClient(ServiceClient.java:150) > > at > org.apache.axis2.client.ServiceClient.<init>(ServiceClient.java:143) > > at > org.apache.axis2.client.ServiceClient.<init>(ServiceClient.java:244) > > at > org.apache.axis2.rpc.client.RPCServiceClient.<init>(RPCServiceClient.java:48) > > at > com.tibco.amf.admin.api.servicefactory.remote.axis2.Axis2ProxyServiceFactory$Axis2ServiceInvocation.<init>(Axis2ProxyServiceFactory.java:185) > > at > com.tibco.amf.admin.api.servicefactory.remote.axis2.Axis2ProxyServiceFactory.createService(Axis2ProxyServiceFactory.java:168) > > at > com.tibco.amf.admin.api.servicefactory.remote.RemoteServicesRegistry.getRemoteServiceInstance(RemoteServicesRegistry.java:112) > > at > com.tibco.amf.admin.cmdline.ServiceFactory.createService(ServiceFactory.java:196) > > at > com.tibco.amf.admin.cmdline.CLIRegistry.getService(CLIRegistry.java:181) > > at > com.tibco.amf.admin.cmdline.Processor.process(Processor.java:104) > > at > com.tibco.amf.admin.cmdline.Processor.processChildren(Processor.java:39) > > at > com.tibco.amf.admin.cmdline.ant.AMXAdminTask.process(AMXAdminTask.java:362) > > at > com.tibco.amf.admin.cmdline.ant.AMXAdminTask.execute(AMXAdminTask.java:280) > > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) > > at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:497) > > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > > ... 35 more > > [2015-05-07 14:46:39,063] [JavaFX Application Thread] INFO > griffon.javafx.JavaFXGriffonApplication - Shutdown is in process > > > > My build.gradle > > ... > > dependencies { > > griffon 'org.codehaus.griffon.plugins:griffon-miglayout-plugin:1.1.1' > > compile > "org.codehaus.griffon:griffon-guice:${griffon.version}" > > //compile 'org.apache.ant:ant:1.9.4' > > compile('org.apache.ant:ant-apache-log4j:1.9.4') { > > exclude group: 'log4j', module: 'log4j' > > } > > > > runtime('log4j:log4j:1.2.17') { > > exclude group: 'ant', module: 'ant-nodeps' > > exclude group: 'ant', module: 'ant-junit' > > exclude group: 'ant-contrib', module: 'ant-contrib' > > } > > runtime 'org.slf4j:slf4j-log4j12:1.7.10' > > //runtime 'org.slf4j:slf4j-jcl:1.7.10' > > //runtime 'org.slf4j:jcl-over-slf4j:1.7.10' > > runtime 'commons-logging:commons-logging:1.1.1' > > runtime 'org.apache.ant:ant-commons-logging:1.9.4' > > > > testCompile 'org.spockframework:spock-core:0.7-groovy-2.0' > > testCompile 'com.jayway.awaitility:awaitility-groovy:1.6.3' > > } > > ... > > > > My interpretation of this exception is: > > 1. SLF4JLocationAwareLog has been loaded from slf4j<1.6 (i.e. > jcl-over-slf4j-1.5.2.jar) > > 2. LocationAwareLogger has been loaded from slf4j>=1.6 (i.e. > slf4j-api-1.7.10.jar) > > 3. I understand that slf4j isn’t binary compatible between 1.5 and > 1.6 – and doesn’t like >1 binding on the classapath > > > > What I don’t understand is if my Griffon/Gradle build project contains { > runtime 'org.slf4j:slf4j-log4j12:1.7.10' } this means I’ve fulfilled > slf4j’s requirement by providing the slf4j api and log4j12 binding. > > > > So ant’s taskdef classpath contains the 1.5.2 API – but I can’t change > these scripts > > For some reason slf4j picks jcl-over-slf4j-1.5.2 (the other choice being > slf4j-log4j12-1.5.2) even though a binding has already been > defined/loaded/used. > > In the interim I can “make the error go away” by: > > > > a) Comment out runtime 'org.slf4j:slf4j-log4j12:1.7.10' – meaning no > logging / noop? > > b) Comment in runtime ‘org.slf4j:jcl-over-slf4j:1.7.10’ – (I don’t > really want JCL) > > > > I’m running out of ideas– do I need to dig into the ant code & try and > change the classpath (remove 1.7.10?) I don’t know if that would work if > classes from 1.7.10 have already been loaded – I’m hoping there’s a really > simple solution I’ve just happened to overlook (like executing ant in a new > process with a new classloader) but if anyone has a suggestion it would be > appreciated. > > > > Cheers, > > Paul > > > > > > > > > > > > > ********************************************************************** > This message is intended for the addressee named and may contain > privileged information or confidential information or both. If you > are not the intended recipient please delete it and notify the sender. > ********************************************************************** > > _______________________________________________ > slf4j-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/slf4j-user >
_______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
