We Keep Coding

javax.servlet.ServletContext is being loaded from multiple dependencies in springboot application

So I have this springboot application which I'm migrating from a WAS to a springboot setup. And I have a couple of JSPs which has to be configured. To accomodate these I added the following dependencies:
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
<version>9.0.22</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<scope>provided</scope>
</dependency>
The application already came with the following dependency which is being used throughout the application:
<dependency>
<groupId>com.ibm</groupId>
<artifactId>com.ibm-jaxrpc-client</artifactId>
<version>6.0</version>
</dependency>
The issue I'm facing is that both these dependencies (jaxrpc-client and tomcat-embed-jasper) have javax.servlet.ServletContext classes in them which is causing the following error:
The method's class, javax.servlet.ServletContext, is available from the following locations:
jar:file:/C:/Users/.m2/repository/com/ibm/com.ibm-jaxrpc-client/6.0/com.ibm-jaxrpc-client-6.0.jar!/javax/servlet/ServletContext.class
jar:file:/C:/Users/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/9.0.30/tomcat-embed-core-9.0.30.jar!/javax/servlet/ServletContext.class
It was loaded from the following location:
file:/C:/Users/.m2/repository/com/ibm/com.ibm-jaxrpc-client/6.0/com.ibm-jaxrpc-client-6.0.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of javax.servlet.ServletContext
I can't afford to remove any of these dependencies. jaxrpc-client is being referenced in the code already in too many places and I need tomcat-embed-jasper to render my jsp pages. I can't exclude the ServletContext class since its not a dependency(If I'm not wrong about the concept of exclusion). Please help with with a way forward with this issue.

I'm not familiar with IBM's jaxrpc client, but I assume, you have this exception in runtime, when trying to load the application.
In this case consider the following approaches:
Use another jax-rpc client library
Consider Loading the code that uses this library with the different class-loader (you'll have to create one classloader for this) to avoid the clash
Kind of paraphrasing the second option. You can "play" (override the order of loading of specific classes) with spring boot classloader as described in this article
I know, this is too general answer, but hopefully its still helpful.
The first solution is by far the easiest way I can think of.
The second solution is doable, however it pretty much depends on how exactly the code that uses the jax rpc client is loaded and used.

Issues Converting Mule Tomcat WAR to Spring Boot

I've been going through the process of converting my Mule project to a Spring Boot application, and have hit a snag I can't seem to figure out.
I'm pretty new to Spring Boot so I'm not sure if my issues lie with it, or with the way I'm doing my mule stuff.
Here is my sample project I've been trying to convert: https://github.com/JustinBell/mule-webapp-example
When I deploy this to a tomcat instance it works great, the issue comes when I try to run it as a Spring Boot application I'm getting this exception:
ApplicationContextException: Unable to start EmbeddedWebApplicationContext due to missing EmbeddedServletContainerFactory bean.
Just as a note I'm moving from mule 3.6.1 to 3.7.0-M1 as that's required (from my understanding) to use Spring Boot.
I've tried looking around for support on this issue which seems to pretty common, but none of the suggestions I've found have solved the issue.
Thanks for any help with these issues!

There are a few things that aren't quite right in your code as it stands.
If you want to build a web app with Spring Boot, you'll typically want to add a dependency on spring-boot-starter-web. This provides, among other things, the embedded servlet container:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>${spring-boot.version}</version>
</dependency>
Your app's dependency on org.mule.transports:mule-transport-servlet pulls in a very old version of Tomcat's Coyote module. You need to exclude this to avoid it clashing with the up-to-date dependency that's provided by spring-boot-starter-web:
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-servlet</artifactId>
<version>${mule.version}</version>
<exclusions>
<exclusion>
<groupId>org.apache.tomcat</groupId>
<artifactId>coyote</artifactId>
</exclusion>
</exclusions>
</dependency>
Your Application class is trying to run MuleContextInitializer which it also declares as a bean. It should be running Application.class:
#SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class);
}
// ...
}
Your Application class is also in the default package. You should avoid using the default package as it will cause Spring Boot to scan then entire classpath looking for your application's classes and configuration. Moving it into a package of its own to stop this from happening.
Lastly, the app fails to launch as it's looking for a file named mule-config.xml. Renaming mule-webapp-demo.xml to mule-config.xml addresses this.

I believe autodelete is an Enterprise feature, perhaps you are using ftp rather than ftp-ee.

Why is Maven not resolving all dependencies for commons-configuration?

Summary
When trying XMLConfiguration configuration = new XMLConfiguration("config/config.xml"); with only commons-configuration 1.10 I need to add more depencies (namely commons-collections not newer than 3.2.1) to my maven setup. Why is that so and why doesn't maven simply resolve all needed dependencies?
Details
I am trying to get commons-configuration to work. First I wanted to use the latest version, 2.0-alpha2, which didn't work well at all since I was unable to configure Maven to download the correct ressources - but that is another story.
After I found out that version 1.10 is in fact "one point ten" (not "one point one zero") and thus the latest version of commons-configuration 1 (and covered by the tutorials), I decided to give it a try instead.
For my maven dependencies (integrated in eclipse) I used:
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.10</version>
</dependency>
However, when trying out this example:
package main;
import java.util.Iterator;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.XMLConfiguration;
public class ConfigurationTest {
public static void main(String... args) {
try {
XMLConfiguration configuration =
new XMLConfiguration("config/config.xml");
Iterator<String> iterator = configuration.getKeys();
while (iterator.hasNext()) {
System.out.println(iterator.next());
}
} catch (ConfigurationException e) {
e.printStackTrace();
}
}
}
with the following config.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<configuration>
<property>value</property>
<nestedproperty>
<arrayvalue>0,1,2,3,4</arrayvalue>
<property>anothervalue</property>
</nestedproperty>
</configuration>
I got the error:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/CollectionUtils
at org.apache.commons.configuration.XMLConfiguration.constructHierarchy(XMLConfiguration.java:640)
at org.apache.commons.configuration.XMLConfiguration.initProperties(XMLConfiguration.java:596)
at org.apache.commons.configuration.XMLConfiguration.load(XMLConfiguration.java:1009)
at org.apache.commons.configuration.XMLConfiguration.load(XMLConfiguration.java:972)
at org.apache.commons.configuration.XMLConfiguration$XMLFileConfigurationDelegate.load(XMLConfiguration.java:1647)
at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:324)
at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:261)
at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:238)
at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.load(AbstractHierarchicalFileConfiguration.java:184)
at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.<init>(AbstractHierarchicalFileConfiguration.java:95)
at org.apache.commons.configuration.XMLConfiguration.<init>(XMLConfiguration.java:261)
at main.ConfigurationTest.main(ConfigurationTest.java:12)
I first hoped they (not me, of course) just screwed up some maven dependencies and since I wouldn't bother which version to use anyway anymore (I didn't get 2.0 to work, remember?) I decided to go down to version 1.9 by replacing the maven dependency with:
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.9</version>
</dependency>
That solved the problem pretty well, the test case is running:
property
nestedproperty.arrayvalue
nestedproperty.property
But when I tried to implement a similar example to the one referenced in Very simple Apache-commons configuration example throws NoClassDefFoundError and its follow-up question I got the exact same error which is referenced there - but the solution, importing org.apache.commons.beanutils.PropertyUtils is not working as I am missing the beanutils. So basically by downgrading I just switched from the error of missing the collections to missing beanutils.
There is a dependency overview where you can see which dependencies are used when you do what. I was a bit suprised to learn that version 1.10 now used other dependencies (namely the CollectionUtils) than 1.9 did in the constructor call. Since there were dependency problems in 1.10 as well as in 1.9 I just sticked to the newer version.
I found the CollectionUtils located in the following artifact (as I was pointed there by its maven repository):
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.0</version>
</dependency>
Sadly that one (not obvious to me at first) doesn't define the class CollectionUtils in the package collections, but in the package collections4. It was hinted at this problem on the dependency overview, but they only mentioned possible problems with earlier versions... I appeared to be at a point of not thinking much about it anymore but simply changed the dependency to:
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
</dependency>
I got everything to work (more or less, but the Exceptions I get now are not anymore depending on missing class definitions) after using these dependencies:
<dependencies>
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.10</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.9.2</version>
</dependency>
</dependencies>
Why do I have to add the dependencies myself? I thought the whole point in using maven is to avoid having to do such things and in terms of javadocs and source files it does a pretty good job.
By now I am convinced that the dependencies are not included in the hierarchy by design (is that so?), probably to avoid overhead. However is there a way to either simply get all dependencies at once or even better to get all dependencies I need? And why is it designed this way?

If we analyse commons-configuration's POM we see that the commons-collections dependency is optional:
<dependencies>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
<optional>true</optional>
</dependency>
...
Furthermore, from the Maven docs:
If a user wants to use functionality related to an optional
dependency, they will have to redeclare that optional dependency in
their own project.

This issue is explained on the Runtime dependencies page of the Commons Configuration website.
Quoting from that page:
A lot of dependencies are declared in the Maven POM. These are all needed during compile time. On runtime however you only need to add the dependencies to your classpath that are required by the parts of the Commons Configuration package you are using. The following table helps you to determine which dependencies you have to include based on the components you intend to use.
The other answers explain why this works from a Maven perspective. This answer is intended to provide a defence, of sorts, to the Commons Configuration folks. They did at least warn you!
In cases where the dependencies are on other Apache Commons components, they've taken the time to test with a variety of versions and have posted information on compatibility at the bottom of that page.

Maven tries to resolve all necessary dependencies for a library you're using in your pom. Well sometimes you have some dependencies which are only necessary for some specific features and you don't want to force the user of your dependency to download it if he doesn't use it. Then you're declaring your dependency as optional. This happened with commons-collections within commons-configuration. See commons-configuration-pom here

WebSphere MQ Configuration issues

getting below error after i configure MQ connection factory.
java.lang.ClassCastException: com.ibm.ejs.jms.JMSQueueConnectionFactoryHandle incompatible with com.ibm.mq.jms.MQQueueConnectionFactory
my code snippet where the exception is pointing to :
String queueConnectionJndi = props.getProperty(queueConnection + MQ_CONN);
queueConnectionFactory = MQQueueConnectionFactory)initialContext.lookup(queueConnectionJndi);
I am not able to find out the root cause of this.
can any body please help me on this, Thanks in advance.

There is no way to be sure without more context, but it looks like this method call:
initialContext.lookup(queueConnectionJndi);
is returning an object of type com.ibm.ejs.jms.JMSQueueConnectionFactoryHandle which cannot be cast to com.ibm.mq.jms.MQQueueConnectionFactory.
Can you provide more context?

This Post on old nabble sounds like a similar issue and may help you out.
Specifically the final response talks about removing any jms.jar file(s) that may be in your deployed WAR. Check your WEB-INF/lib. Certain jars are provided by the Websphre container and shouldn't be including them in your WAR.
This Post on the spring fourm also indicates issues of this nature caused by jars included in the classpath that shouldn't be there
Remove any of the following if you find them...
naming.jar
providerutil.jar
jndi.jar
jms.jar
mq.jar
websphere.jar

Can you rewrite your code to use JMS standard (ConnectionFactory or QueueConnectionFactory)instead of a Websphere MQ specific implementation class? That way you won't be tying your app to Websphere MQ and porting it to an alternative MQ implementation would be easier...
i.e.
import javax.jms.QueueConnectionFactory;
...
queueConnectionFactory = (QueueConnectionFactory)initialContext.lookup(jndiName);

the MQ jars which WAS is using and my application using are different so this problem occured. when i corrected the classpath it is resolved. sorry for the trouble, thanks for the help.

I went through a lot of trial and error to find the answer (the answer to my question at least). I hope this solution will solve your issues too. As mentioned from another post excluding the jms library works. But how do you exclude the jms library and still be able to compile the code? That was something no one seems to have mentioned. The solution to that is to make the scope for the jms library to "provided" (if you are using Maven or Gradle).
As mentioned somewhere:
"Provided means that you need the JAR for compiling, but at run time there is already a JAR provided by the environment so you don't need it packaged with your app. For a web app, this means that the JAR file will not be placed into the WEB-INF/lib directory."
So in your pom.xml add/update these:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jms</artifactId>
<version>4.3.4.RELEASE</version>
<exclusions>
<exclusion>
<groupId>javax.jms</groupId>
<artifactId>javax.jms-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>javax.jms</groupId>
<artifactId>jms</artifactId>
<version>1.1</version>
<scope>provided</scope>
</dependency>
Hopefully this can be helpful to those who have been frustrated by the lack of answers from the Internet.
Remove all the ibm libraries. They are useless. Once you deploy onto Websphere, it will use its libraries anyways.

Whats the root cause of Log4JLogger' cannot be found or is not useable?

I have commons-logging.jar (v1.0.4) and log4j-1.2.8.jar in the classpath and getting following run-time error:
Caused by: org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable.
at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:874)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:310)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)

If you using Maven, you must ensure declare commons-logging and log4j in pom.xml
<dependencies>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.3</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
</dependencies>
if you declare only commons-logging you with getting error Log4JLogger cannot be found or is not useable

This was a classpath problem and we did have another version of log4j in the classpath. Thanks Nathan Ryan !

Had this problem using log4j-2.x with commons-logging-1.2. Reverted back to log4j 1.2.x and all is fine with the world.

There is an answer here
Commons-logging with log4j2
Include the library:
log4j-jcl
See also:
https://logging.apache.org/log4j/2.x/faq.html#which_jars

I see this error sometimes when I try to run a web application on tomcat 7 in my eclipse 3.6 . It occurs out of nowhere just by restarting eclipse.
After several (!) "clean all projects" and new deployments of the web app on the server the application runs again. Maybe someone else knows the exact "spell" to solve this mystery without trial and error?

If you are providing an implementation for a logger, the implementation must define a constructor that takes a java.lang.String as an argument. Otherwise you get an "org.apache.commons.logging.LogConfigurationException: User-specified log class '...' cannot be found or is not useable." The faq page of the apache wiki states so.
Are you creating any specific project like web-services or spring, etc? If yes, then please analyze the project specific property files which would have a property in reference to the Logger, something like
<property name="logger">javax.servlet,org.apache.commons.logging</property>
if you have a java project with servlets.

I received this same exception.
I do have an implementation of logger.
It did not have a constructor that takes a String as an argument.
I implemented such a constructor and that solved the problem for me.

I was getting this error when apache commons logging jar was there in my classpath but log4j jar was somehow missing. Once I added log4j jar to my class path, this error was gone.

This error seems to be pretty generic. To get more details, start up the JVM with this option:
-Dorg.apache.commons.logging.diagnostics.dest=STDOUT
In my case, found some missing dependencies.
[LogFactoryImpl#929338653 from sun.misc.Launcher$AppClassLoader#1442407170] Attempting to instantiate 'org.apache.commons.logging.impl.Log4JLogger'
[LogFactoryImpl#929338653 from sun.misc.Launcher$AppClassLoader#1442407170] Trying to load 'org.apache.commons.logging.impl.Log4JLogger' from classloader sun.misc.Launcher$AppClassLoader#1442407170
[LogFactoryImpl#929338653 from sun.misc.Launcher$AppClassLoader#1442407170] Class 'org.apache.commons.logging.impl.Log4JLogger' was found at 'jar:file:/home/mcadiz/NetBeansProjects/LogFilter/dist/lib/commons-logging-1.2.jar!/org/apache/commons/logging/impl/Log4JLogger.class'
[LogFactoryImpl#929338653 from sun.misc.Launcher$AppClassLoader#1442407170] The log adapter 'org.apache.commons.logging.impl.Log4JLogger' is missing dependencies when loaded via classloader sun.misc.Launcher$AppClassLoader#1442407170: org/apache/log4j/Priority
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable.
at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:804)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:541)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:292)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:269)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655)
at com.oracle.logfilter.LogEntry.<clinit>(LogEntry.java:19)
Adding the log4j.jar to the classpath fixed the issue.

I was facing this problem and found out that it was due to a classpath conflict related to log4j jar.
As I was using maven in my project, the fix was to add a dependency management for log4j as below.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
</dependencies>
</dependencyManagement>