My WEB-INF/lib contains "jackson-core-2.8.10.jar" which contains the necessary class file. In fact I am able to create objects for other classes in the same jar, so it isn't as f the jar itself is invisible somehow. But when running on Tomcat I am getting a ClassNotFoundException. I am posting the stacktrace below. This error has been giving me nightmares for the past week. Absolutely any sort of hint will be appreciated. Please feel free to call me an idiot.
Tomcat version: Apache Tomcat/8.5.23
Java version: 1.8.0_151
I am getting the exception in the following line:
Same code, same test cases running on a windows machine with same Java and Tomcat machine. Unfortunately, don't have access to the pc whole time otherwise I would have developed on it. Even stranger, when I try to place a try catch around the statement to catch the particular error I get:
Error:(61, 11) java: exception com.fasterxml.jackson.core.JsonProcessingException is never thrown in body of corresponding try statement
Here's the stack trace when I receive the request.
2017-10-26 05:23:22.110 ERROR 7422 --- [nio-8080-exec-2] o.s.boot.web.support.ErrorPageFilter : Forwarding to error page from request [/token] due to exception [com/fasterxml/jackson/core/JsonProcessingException]
posted 1 year ago
Sorry for the confusion but I can't seem to find the edit function on the original post. The class that I created an object for was in jackson.databind. So, Tomcat may actually not be able to find the JAR. Again, really sorry for that mistake.
posted 1 year ago
Found the answer to the issue myself. Turns out there was a jjwt 0.8 jar present in the jvm/ext folder (which I must have placed some time ago, accidentally or intentionally - doesn't matter) so instead of resolving the jjwt jar from the WEB-INF/lib it was getting resolved at jvm/ext. I had previously noticed this but assumed the issue has nothing to do with this as I expected the other jar would be found elsewhere.
Turns out since the jjwt was present in jvm/ext folder the class loader was looking for its dependency in the same folder without looking for it anywhere else, like the WEB-INF/lib.
This is likely because class loaders work in hierarchies different loaders look at different levels. The Bootstrap loader in this instance looks for class files in jvm/ext. The WEB/INF/lib responsible loader is the WebappX loader. So in short, I deleted the jar in jvm/ext and all is well in the world again.
Yeah, I've been burned by that before. Sometimes it seems like a good idea to put a jar into the extensions library, then all those classpath problems go away. But when you forget you did that (yes, I'm talking about me too) then suddenly it wasn't a good idea after all. Thanks for posting back with the answer to your problem, and I gave you a cow for that.
Yeah. I don't muck with the JVM's class directories. Firstly, because you can run into problems regarding endorsement, secondly because I juggle a lot of machines and JVMs and I don't need the frustration of remembering what JVM is customized how. Thirdly, because you can get into the JAR equivalent of "DLL Hell", as you've discovered.
And fourthly, in the case of Tomcat, if I must make a jar globally shared, I'd put it in the TOMCAT_HOME/lib directory.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.