So you’ve developed a portlet, perhaps using the latest displaytags taglib, version 1.2. You have your portlet project being built via Maven, and you are deploying locally on the Liferay EE 6.1 Tomcat bundle. Life is good, all goes smoothly, and you are excited to now demo your portlet to the stakeholders. So you take your build artifacts (the war file) and you copy it up to your demo server and deploy it. It fails, with an interesting message such as:
Caused by: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)
I chose displaytags not to pick on it, but because it has a dependency on slf4j, specifically, slf4j 1.4.2, and was the reason the above mentioned error occurring.
In this case, the first error message, which occurred in JBoss, was the result of having explictly specified slf4j 1.4.2 in my pom.xml. A quick check showed that Liferay EE 6.1 uses slf4j 1.6.4, so with a quick grumble about API’s that fail to be backwards compatible, the pom.xml was updated and the portlet rebuilt and deployed, locally, to the Tomcat bundle for a sanity check. It failed with the similar message.
Digging a little deeper, JBoss uses slf4j 1.6.1. Utilizing this dependency resulted in a successful deployment.
I should add some followup notes here: during the course of the deployments, we also stopped the servers and cleaned up all temp and work directory files, removing all traces of potentially incorrect jar files. In follow up attempts to recreate the problems quickly for this article, I skipped this cleanup step resulting in working scenarios that previously failed. So when facing third party jar versioning issues across multiple components and classloaders such as slf4j, log4j and others, always take the safe route and stop your server and clean out the offending components before attempting to redeploy the component, or you may have resolved the issue and not see the effects due to old cached versions.