Develop Reference

log4j and log4j-overslf4j both in classpath conflicts in LogManager

we are using log4j-over-slf4j for logging in our application. But one of jar dependency in our application(External to us) needs log4j specific class(org.apache.log4j.spi.RepositorySelector). So, I have added log4j also in our classpath and It was able to find that class,
But, then I start to face new issue, In my code, I am loading RepositorySelectorfrom LogManager,
LogManager.setRepositorySelector(repoSel, guard);
Now, instead of referring to log4j specific LogManager, It is referring to log4j-over-slf4j specific LogManager, due to which , I am getting below error in websphere server console.
Caused by: java.lang.NoSuchMethodError: org/apache/log4j/LogManager.setRepositorySelector(Lorg/apache/log4j/spi/RepositorySelector;Ljava/lang/Object;)V**
Please help me know, how can we remove the conflict, so that, It's able to refer proper log4j1.2.15 specific LogManager.
And, as jar which is using log4j is external to our system, we don't have much control over that.
Below is the complete stack trace.
Caused by: java.lang.NoSuchMethodError: org/apache/log4j/LogManager.setRepositorySelector(Lorg/apache/log4j/spi/RepositorySelector;Ljava/lang/Object;)V
at com.hsbc.es.logging.def.impl.log4j.Log4jLoggingTypeProvider.setContextualRepositorySelector(Log4jLoggingTypeProvider.java:117)
at com.hsbc.es.logging.def.impl.log4j.Log4jLoggingTypeProvider.<clinit>(Log4jLoggingTypeProvider.java:97)
at java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1887)
at com.hsbc.es.logging.LoggingTypeManagerFactory.discoverContextLoggingTypeManagerSPI(LoggingTypeManagerFactory.java:168)
at com.hsbc.es.logging.LoggingTypeManagerFactory.getContextLoggingTypeManagerSPI(LoggingTypeManagerFactory.java:98)
at com.hsbc.es.logging.def.LoggingTypeProviderFactory.getContextLoggingTypeProvider(LoggingTypeProviderFactory.java:49)
at com.hsbc.es.logging.def.LoggingTypeFactory.getDebugger(LoggingTypeFactory.java:58)

You can exclude the transitive log4j dependency from being imported by the dependency that includes it.
In your pom.xml you can tell update your dependency import in order to exclude log4j:
<dependencies>
<dependency>
<groupId>the.group.id</groupId>
<actifactId>the.artifact.id</artifactId>
<version>version-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>

hibernate-entitymanager NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V

I'm deploying an EAR application built with Maven which has the following dependency in one of the modules:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>5.1.0.Final</version>
</dependency>
When I try to deploy the application in a Glassfish Server 4.1 I get the following error:
Fatal: java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V
at org.hibernate.internal.NamedQueryRepository.checkNamedQueries(NamedQueryRepository.java:149)
I made some research to solve this problem and made the following attempts:
First Attempt
I found this question and used the script in this article to clean the Glassfish's osgi-cache, as suggested in the question and in this issue of the Glassfish/Payara Github repository. Restarted the server. Same error.
Second Attempt
I found this question and tried the suggestion of the first answer, like this: looking at the dependency tree, I see that hibernate-entitymanager has the following dependency:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
<scope>compile</scope>
</dependency>
So I searched at my Server installation and found the jboss-logging.jar. The installed version was 3.1.0-GA (I'm not sure right now, but surely it was a previous version of the dependency). I downloaded jboss-logging-3.3.0.Final.jar from the Maven Central Repository and replaced the one in my Server installation. Restarted the server. Same error.
Third Attempt
Some comments in the previous post (and others) suggested to add a property org.jboss.logging.provider=slf4j as I'm using these dependencies for logging:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.21</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.21</version>
<scope>test</scope>
</dependency>
I found some .properties files in the /glassfish/domains/domain1/config/ folder but none of them contains such a property and I don't know in which file to add that property. I also made some search in the Admin Console but I didn't found where to add properties. The only logging configuration I found was to configure logging levels.
After that I found where to put some JVM options for the Glassfish Server in the Admin Console and added -Dorg.jboss.logging.provider=slf4j as an option but did not work for me (even more, I had to reboot my computer to get Glassfish in ground zero)
Fourth Attempt
Before all this I had a problem and made another question in StackOverflow. Guided by this comment in that post I changed the project configuration but nothing happened (I solved that problem with a little change in my dependencies, answer still pending)
After all the attempts, I'm running out of ideas and the problem remains. I don't know what could be the problem. Any guide, help or answer will be really appreciated. If anybody needs more details about the situation just let me know.
Thanks in advance for your collaboration.
EDIT 1
I was searching and found this article which says something similar to what I did and adds a provided dependency for jboss-logging like this:
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final</version>
<scope>provided</scope>
</dependency>
But the error remains. Apparently it's something with the Server but I can't figure out what. I'm using GlassFish Server Open Source Edition 4.1 (build 13)

I was using JBoss server 7.1 to deploy my project. In my case this error was due to the fact that the I was using jboss-logging-3.3.0.Final.jar in my project but the JBoss 7 had a jboss-logging-3.1.0.GA.jar (/opt/jboss-as-7.1.1.Final/modules/org/jboss/logging/main/) by default. So, may be this was due to the jar conflict or method was not present in the jboss-logging-3.1.0.GA.jar, I am not sure. But replacing the jboss-logging-3.1.0.GA.jar with jboss-logging-3.3.0.Final.jar and change mapping in module.xml (at the same above mentioned location) as follows
<module xmlns="urn:jboss:module:1.1" name="org.jboss.logging">
<resources>
<resource-root path="jboss-logging-3.3.0.Final.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.logmanager"/>
</dependencies>
</module>
And the error was gone. Hope it helps.

This is because GlassFish ships with an earlier version of JBoss Logging and this is being picked up by your application hence the NoSuchMethod error. The version of JBoss Logging shipped with GlassFish 4.1 does not have the method defined. You can try and replace the version of jboss-logging in the modules directory of glassfish this may or may not work but it looks like you tried and failed with this approach.
Another option is to upgrade to the latest Payara 4.1.1.162 which ships with JBoss Logging 3.3.0.Final.

Block Glassfish for using its own lib when project lib is provided
Just create a glassfish-web.xml file in the WEB-INF directory. The contents of the file are shown below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
 <class-loader delegate="false"/>
</glassfish-web-app>
This ensures that glassfish does not load it's internal libraries, but libraries from your project.

NoSuchMethodError on startup in Java Jersey app

I've been getting a very strange error when trying to start a Jersey app on Tomcat. The same code works on other computers. I tried reinstalling tomcat, all my maven dependencies, even Eclipse and Java itself, no luck. It seems like a bad Jersey version is being loaded, I think?
Any pointers in the right direction will be appreciated.
Here's the effective pom: http://pastebin.com/NacsWTjz
And the actual pom: http://pastebin.com/H6sHe4ce
2015-02-13 13:43:40,870 [localhost-startStop-1] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/middleware-server] - StandardWrapper.Throwable
java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:304)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:311)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1031)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4901)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5188)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1399)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Note: Please see above comments for further discussion and tips.
This error usual means that you have a both a JAX-RS 1 and JAX-RS 2 jar on the classpath. Jersey 2 uses JAX-RS 2 (javax.ws.rs-api-2.0.1.jar), but if you have the jsr311-api.jar also, which is JAX-RS 1, there is a javax.ws.rs.core.Application in each jar. But the jsr311-api Application doesn't have the method getProperties() (hence NoSuchMethodError).
I've come to the conclusion that all you need to do is add the above exclusion to the swagger dependency. The Jackson 2.0 provider (which depends on JAX-RS 1) seems to be overridden by a 2.4.1 provider (which uses the new version). So we don't need to add it ourselves. When it's overridden, it seems to leave behind the jsr311-api.jar. So if we exclude it, no one can attempt to use it, which looks to be the current problem
<dependency>
<groupId>com.wordnik</groupId>
<artifactId>swagger-core_2.10</artifactId>
<version>1.3.11</version>
<exclusions>
<exclusion>
<groupId>javax.ws.rs</groupId>
<artifactId>jsr311-api</artifactId>
</exclusion>
</exclusions>
</dependency>

We are using jersey-json 1.9 which has a dependency on jersey-core which also happen to have a javax.ws.rs.core.Application class.
So our fix is to exclude the jersey-core from jersey-json:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>1.9</version>
<exclusions>
<exclusion>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-core</artifactId>
</exclusion>
</exclusions>
</dependency>

the problem is related about "com.sun.jersey:jersey-core:jar:1.18.3" (or any 1.* version) because old versions of Jersey didn't have that "public Map getProperties()" method.
And one of your dependencies use Jersey version 1 (you can check that in running mvn dependency:tree and search all jersey-core version used)
Me I have resolved the problem deleting all com.sun.jersey dependancies (old api) and using the new one org.glassfish.jersey API
https://mvnrepository.com/artifact/org.glassfish.jersey.core

Calling JSP files gives a NoSuchMethodError when app deployed outside of Eclipse

I have a maven project that works completely as intended inside of eclipse. It also builds and runs outside of eclipse, but when I try to call the frontend (JSP web pages) then I get the following:
Problem accessing /. Reason:
javax.servlet.ServletContext.getJspConfigDescriptor()Ljavax/servlet/descriptor/JspConfigDescriptor;
Caused by:
java.lang.NoSuchMethodError:
javax.servlet.ServletContext.getJspConfigDescriptor()Ljavax/servlet/descriptor/JspConfigDescriptor;
...
I've looked around and it seems that this message is associated with an incompatibility between Servlet 2.5 and Servlet 3.0. But I already have Servlet 3.0 as a dependency in my pom:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
</dependency>
So I can't figure out why this dependency that I need isn't being included when I build and deploy outside of eclipse even though the build itself is successful.
Any idea what could be causing this and how to fix it?
EDIT:
The JSP access isn't configured in web.xml. The index.jsp file is the welcome file set for the jetty server with this snippet:
// configure webapp
WebAppContext webroot = new WebAppContext();
webroot.setResourceBase("src/main/webapp");
webroot.setContextPath("/");
webroot.setWelcomeFiles(new String[] {"index.jsp"});
webroot.setParentLoaderPriority(true);
server.setHandler(webroot);
The remaining few jsp files are in the webapp folder.
EDIT 2:
I've examined the contents of the jar created when packaging my project and it appears that there are multiple copies of the javax/servlet/Servlet.class in the jar. This is a bit perplexing. I'm assuming that these other dependencies (listed below) that I have in my pom must be adding the additional Servlet.class files.
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
<version>8.1.8.v20121106</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-webapp</artifactId>
<version>8.1.8.v20121106</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-jsp</artifactId>
<version>8.1.8.v20121106</version>
</dependency>
But I'm not sure how to fix any of this...
If anyone has any ideas, I'd love to hear them. The only real constraints that I have is that I have to use jetty 8.1.8.v20121106.

It seems to me you might be deploying a servlet 3.0 on tomcat 6 which is not supported and would cause this exception.
An additional possibility is that your exporting additional .classes within your war that are interfering with tomcat's default libraries.

Android: error including/repacking dependencies which reference javax core classes

I'm working on an Android app using Maven as the build tool. I managed to set evertyhing up correctly (maven dependencies are exported to the apk etc.), however I have one remaining problem which is driving me crazy.
I want to include a dependency on simpleframework's xml parser defined as follows in my POM file:
<dependency>
<groupId>org.simpleframework</groupId>
<artifactId>simple-xml</artifactId>
<version>2.5.3</version>
</dependency>
When I issue mvn install on the project, I get the following error (truncated):
trouble processing "javax/xml/namespace/NameSpaceContext.class" ...
I know the error results from the simple xml parser referencing these javax-classes, however I haven't found a solution yet (setting the --core-library flag is of no use).
I'm currently trying to repack the dependency with the maven-jarjar-pluging but this doesn't seem to work either.
Can anyone help me out with this? Many, many thanks in advance!

Define your simple-xml depedency like this :
<dependency>
<groupId>org.simpleframework</groupId>
<artifactId>simple-xml</artifactId>
<version>2.6.1</version>
<exclusions>
<!-- StAX is not available on Android -->
<exclusion>
<artifactId>stax</artifactId>
<groupId>stax</groupId>
</exclusion>
<exclusion>
<artifactId>stax-api</artifactId>
<groupId>stax</groupId>
</exclusion>
<!-- Provided by Android -->
<exclusion>
<artifactId>xpp3</artifactId>
<groupId>xpp3</groupId>
</exclusion>
</exclusions>
</dependency>

I use android-maven-plugin, and adding <coreLibrary>true</coreLibrary> to the <configuration> tag of the plugin in the POM works for me. However, there's a bug: https://github.com/jayway/maven-android-plugin/pull/34, that you need to include to fix the plugin you are using, since the bug won't be fixed until 3.0. Here's how I got it working for me using 2.9.0-SNAPSHOT.
add a pluginRepository pointing to http:// oss.sonatype.org/content/repositories/jayway-snapshots/ to get 2.9.0-SNAPSHOT
update your plugin version to use 2.9.0-SNAPSHOT and add <coreLibrary>true</coreLibrary> to pom.xml
get the fix: git clone https://github.com/kevinpotgieter/maven-android-plugin.git
remove src/test/java/com: so the test won't fail
mvn package
copy it and overwrite your local maven cache in .m2 (You may need to remove your plugin repository yours gets overwritten every time.)
Step 3-6 won't be necessary after the fix gets into 2.9.0-SNAPSHOT.
Update July 2010: 2.9.0-beta-4 has the fix, so you don't need the above workaround if you use 2.9.0-beta-4 or later. I tested 2.9.0-beta-5 which worked just fine.

Spring Android uses Maven to integrate Simple. Take a look at the following URL, it should provide pointers on how to get Maven working with Simple.
http://static.springsource.org/spring-android/docs/1.0.x/reference/html/rest-template.html