We Keep Coding

NoSuchMethodError in org.json.JSONObject after kubernetes upgrade from 1.21 to 1.23

I don't know if the kubernetes upgrade has anything to do with the problem, but it's the only change I know of between the time the application was working as expected and when it started throwing this exception.
I have some code in a Spring Boot app that adds a List<Object> to a JSONObject. The line looks like this:
jsonObject.put("some_name", someList);
This code hasn't been touched in a year, but suddenly started throwing this exception after a k8s upgrade from 1.21 to 1.23:
org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.NoSuchMethodError: 'org.json.JSONObject org.json.JSONObject.put(java.lang.String, java.util.Collection)' at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1082)
[...]
Caused by: java.lang.NoSuchMethodError: 'org.json.JSONObject org.json.JSONObject.put(java.lang.String, java.util.Collection)' at com.example.service.MyClass.convertToJson(MyClass.java:109)
The k8s upgrade also included a change from Java 17.0.5+8 to Java 17.0.6+10, but everything runs as expected locally using both of those JDK versions.
I ran a mvn dependency tree -Dverbose and couldn't find anything weird there either. These were the only entries that had to do with json.
org.json:json:jar:20220320
org.springframework.boot:spring-boot-starter-json:jar:2.6.4
I'm out of ideas for what might be causing this issue, so any suggestions on what to look at next are welcome.

It could be that the version of org.json:json included in your project is out of date, and doesn't include the put(String, Collection) method you're trying to use. Try updating this dependency to a more recent version and seeing if that resolves the issue. It's also possible there are some other dependencies in your project which conflict with org.json:json or override it with an older version - check for any similarly named libraries (e.g., json-simple instead of org.json). You may also want to check the version of Spring Boot you're using, as this might be incompatible with the org.json library you're trying to use.

Mule 3.7.3 and Jackson 2.9.0 issues-NoSuchMethodError

I am having lots of issues getting Mule to work with Jackson classes. The classes present in my final library only have the following files. To eliminate the possibility of maven pulling in other jackson libraries, I create a mule project without using maven and simply pull in the bare minimum libraries. However, it is failing with NoSuchMethodError for CSVMapper().reader(MyClass) etc. and later with
Caused by: java.lang.NoSuchMethodError:
com.fasterxml.jackson.databind.JsonMappingException.<init>
(Ljava/io/Closeable;Ljava/lang/String;)V
jackson-core-2.9.0.jar
jackson-databind-2.9.0.jar
jackson-annotations-2.9.0.jar
jackson-dataformat-csv-2.9.0.jar
I get NoSuchMethodError when I call methods that are definitely in the classpath. To make matters worse the program runs fine outside of Mule.
It turns out that the following module mule-core.3.7.3 has an older version of Jackson i.e. 2.4.3. Unfortunately what works with version 2.9.0 now fails with
Too many entries: expected at most 1 (value #1 (18 chars) "20170822211046.581")
How can solve this problem?

I solved it by using the Jackson libraries provided by Mule i.e. version 2.4.3 for converted JSON to Java objects. For the CSV conversion to Map I used apache commons-csv replacing Jackson's CSVMapper.

NoSuchMethodFound error: dependency error in GWTP. ResourceDelegate usage

I'm working in a GWTP + GAE project based on the CarStore example delviered by ArcBees. Maven dependencies are taken from that project too. My current version of GWTP is 1.5-SNAPSHOT.
The project compiles perfectly well. But when I run it, I'm stucked in this error:
[ERROR] Error injecting com.gwtplatform.dispatch.rest.delegates.client.ResourceDelegate<com.rmideas.sportbinder.shared.api.SessionResource>:
Unable to create or inherit binding: No #Inject or default constructor found for com.gwtplatform.dispatch.rest.delegates.client.ResourceDelegate<com.rmideas.sportbinder.shared.api.SessionResource>
The error refers to the ResourceDelegate declared in LoginPresenter. But i can´t find anything wrong in my code.
I analyzed the stacktrace and found this cause:
[INFO] Caused by: java.lang.NoSuchMethodError: com.gwtplatform.dispatch.rest.rebind.events.RegisterGinBindingEvent.postSingleton(Lcom/google/common/eventbus/EventBus;Lcom/gwtplatform/dispatch/rest/rebind/utils/ClassDefinition;Lcom/gwtplatform/dispatch/rest/rebind/utils/ClassDefinition;)
[INFO] at com.gwtplatform.dispatch.rest.delegates.rebind.DelegateGenerator.maybeRegisterGinBinding(DelegateGenerator.java:162)
This refers to a call between two Class objects. DelegateGenerator is the caller and is obtained from this dependency:
<dependency>
<groupId>com.gwtplatform.extensions</groupId>
<artifactId>dispatch-rest-delegates</artifactId>
<version>${gwtp.version}</version>
<scope>provided</scope>
</dependency>
And RegisterGinBindingEvent is the receiver. It belongs to here:
<dependency>
<groupId>com.gwtplatform</groupId>
<artifactId>gwtp-dispatch-rest</artifactId>
<version>${gwtp.version}</version>
<scope>provided</scope>
</dependency>
Now, this happens in line 162 of DelegateGenerator:
RegisterGinBindingEvent.postSingleton(eventBus, definition, getClassDefinition());
This shouldn't be a problem, but the key the eventBus sends as the first parameter is of a different type in both classes.
DelegateGenerator has this import statement:
import com.google.common.eventbus.EventBus;
And RegisterGinBindingEvent has this EventBus class:
import com.gwtplatform.dispatch.rest.rebind.utils.EventBus;
I guess that this is causing the problem. Both dependencies are using the same version (1.5-SNAPSHOT). If I downgrade the version to 1.4, this won´t happen. But it still has issues running ResourceDelegate with this code.
Does anyone know what am I be doing wrong? Or if this is a bug?

Thanks for using the snapshots.
For some reason the CI didn't deploy a snapshot for the last commits. This should now be fixed. Can you try another build? Add -U to your maven command line to make sure you grab the latest snapshot.

Set the JAXB context factory initialization class to be used

I have updated our projects (Java EE based running on Websphere 8.5) to use a new release of a company internal framework (and Ejb 3.x deployment descriptors rather than the 2.x ones). Since then my integration Tests fail with the following exception:
[java.lang.ClassNotFoundException: com.ibm.xml.xlxp2.jaxb.JAXBContextFactory]
I can build the application with the previous framework release and everything works fine.
While debugging i noticed that within the ContextFinder (javax.xml.bind) there are two different behaviours:
Previous Version (Everything works just fine): None of the different places brings up a factory class so the default factory class gets loaded which is com.sun.xml.internal.bind.v2.ContextFactory (defined as String constant within the class).
Upgraded Version (ClassNotFound): There is a resource "META-INF/services/javax.xml.bind.JAXBContext" beeing loaded successfully and the first line read makes the ContextFinder attempt to load "com.ibm.xml.xlxp2.jaxb.JAXBContextFactory" which causes the error.
I now have two questions:
What sort is that resource? Because inside our EAR there is two WARs and none of those two contains a folder services in its
META-INF directory.
Where could that value be from otherwise? Because a filediff showed me no new or changed properties files.
No need to say i am going to read all about the JAXB configuration possibilities but if you have first insights on what could have gone wrong or help me out with that resource (is it a real file i have to look for?) id appreciate a lot. Many Thanks!
EDIT (according to comments Input/Questions):
Out of curiosity, does your framework include JAXB JARs? Did the old version of your framework include jaxb.properties?
Indeed (i am a bit surprised) the framework has a customized eclipselink-2.4.1-.jar inside the EAR that includes both a JAXB implementation and a jaxb.properties file that shows the following entry in both versions (the one that finds the factory as well as in the one that throws the exception):
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
I think this is has nothing to do with the current issue since the jar stayed exactly the same in both EARs (the one that runs/ the one with the expection)
It's also not clear to me why the old version of the framework was ever selecting the com.sun implementation
There is a class javax.xml.bind.ContextFinder which is responsible for initializing the JAXBContextFactory. This class searches various placess for the existance of a jaxb.properties file or a "javax.xml.bind.JAXBContext" resource. If ALL of those places dont show up which Context Factory to use there is a deault factory loaded which is hardcoded in the class itself:
private static final String PLATFORM_DEFAULT_FACTORY_CLASS = "com.sun.xml.internal.bind.v2.ContextFactory";
Now back to my problem:
Building with the previous version of the framework (and EJB 2.x deployment descriptors) everything works fine). While debugging i can see that there is no configuration found and thatfore above mentioned default factory is loaded.
Building with the new version of the framework (and EJB 3.x deployment descriptors so i can deploy) ONLY A TESTCASE fails but the rest of the functionality works (like i can send requests to our webservice and they dont trigger any errors). While debugging i can see that there is a configuration found. This resource is named "META-INF/services/javax.xml.bind.JAXBContext". Here are the most important lines of how this resource leads to the attempt to load 'com.ibm.xml.xlxp2.jaxb.JAXBContextFactory' which then throws the ClassNotFoundException. This is simplified source of the mentioned javax.xml.bind.ContextFinder class:
URL resourceURL = ClassLoader.getSystemResource("META-INF/services/javax.xml.bind.JAXBContext");
BufferedReader r = new BufferedReader(new InputStreamReader(resourceURL.openStream(), "UTF-8"));
String factoryClassName = r.readLine().trim();
The field factoryClassName now has the value 'com.ibm.xml.xlxp2.jaxb.JAXBContextFactory'
Because this has become a super lager question i will also add a bounty :)
I will work the entire day on this and let you know if there is any news.
Update/ Solution
This question has been solved. The original problem has occured because misconfiguration of complexly build multi model maven projects which one dependency used a updated version of a customized eclipse link jar that contained a definition for a JAXBFactory not available in the component where the error occured. Setting the JAXB context factory in most cases is configured with a jaxb.propertie file or JAXBContext file that contains the same definition. Detailed loading process of the appropriate JAXBContextFactory happens in javax.xml.bind.ContextFinder.
The error has not yet been solved (during the fact over 4 major EE/SE Applications lead to the error) and there is no general answer but that defined JAXBContextFactorys must exist in your classpath (wow what a wonder...) so you either have a that ClassNotFound Error because youre missing resources (well thats the acctual cause) or because you have a wrong JAXBContextFactory defined in any of the above mentioned propertie files which contain a definition according to the below answer.
Very many thanks for your great comments and support, i realy appreciate!

You can include a jaxb.properties file in the same package as your domain model to specify the JAXB (JSR-222) implementation you wish to use. For example it would look like the following to specify EclipseLink MOXy as your JAXB provider.
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
For More Information
http://blog.bdoughan.com/2011/05/specifying-eclipselink-moxy-as-your.html

Another quick and dirty solution (a workaround, really) that worked for me is to explicitly include a JAXB implementation to the maven build. For example
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2.7</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.2.7</version>
</dependency>
Note that this adds a somehow unnecessary dependency to your build, as JAXB obviously already is part of each JRE >= version 6.
Most likely this will only work when the WAS classloader is set to parent last.

Jackson + Tomcat - java.lang.VerifyError: Cannot inherit from final class

I have a Java webservice running in Tomcat 6 which accepts JSON input. I am trying to use Jackson ObjectMapper to parse the input json. But when initializing the ObjectMapper object I am getting this error
16:08:13,616 ERROR [[jersey]] Servlet.service() for servlet jersey threw exception
java.lang.VerifyError: Cannot inherit from final class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2733)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1124)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1612)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491)
at com.test.project.offline.ws.WsApiResource.updateData(WsApiResource.java:169)
.......
At line 169 I have this ObjectMapper mapper = new ObjectMapper();
When calling com.test.project.offline.ws.WsApiResource.updateData() method locally in a unit test it works without any error.
Kindly help me in fixing this. I am using Jackson 1.8.4 and tomcat 6.
UPDATE: Fixed the issue. Problem was a different version of jackson in the dependency tree. Excluding it fixed the problem.

I also had the same issue with Apache Lucene. I had lucene-core-3.6.0.jar and lucene-core-3.5.0.jar in my /WEB-INF/lib folder. Removing one or the other also fixed my problem. It must be a versioning issue.

I had the same issue with Apache Solr, and it was resolved by deleting my ~/.m2 cache.
This issue was also caused by specifying the wrong version of a dependency in my pom.xml file, where another package was automatically downloading another version.
Maven really should have some sort of conflicting versions of dependency resolution scheme...

The same for me - my ejb3 application uses jackson-all-1.9.4 - and my glassfish container (v2.1) contains a lib/jackson-asl-0.9.4.jar:
java.lang.VerifyError: Cannot inherit from final class
Now, I have replaced jackson-all with gson.
Thanks,
Danny

Neil has a great answer to this question. However, aside from your M2 cache, check if you're a complete DUMMY like I WAS and ensure your POM doesn't include two packages where the same Final class is declared. Google API's are notorious for cross including classes in their API Jars. Ensure you delete EVERYTHING you don't need!