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.

ClassCastException: Cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor

I have a SOAP webservice that I am trying to call inside of an application. I am using the cxf-codegen-plugin (3.1.10) to generate sources from the WSDL.
Using the generated client, if I call the webservice within the application, it works great. However, I am also using another JAXB instance against the same package within the application which is causing an issue.
For example, the following works great:
OutboundServicePortType service = new OutboundService().getOutboundServicePort();
service.sendMessage(message);
However, initializing a new JAXB instance right before causes the getOutboundServicePort() call to fail:
JAXBContext.newInstance(SendMessageRequest.class);
OutboundServicePortType service = new OutboundService().getOutboundServicePort();
service.sendMessage(message);
With the following stacktrace:
Caused by: java.lang.ClassCastException: outbound.model.standard.StandardOutboundMessage$JaxbAccessorF_messageUUId cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190)
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179)
at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271)
at com.sun.xml.internal.bind.v2.runtime.property.SingleElementLeafProperty.<init>(SingleElementLeafProperty.java:77)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:113)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:166)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:488)
at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:153)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:488)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:305)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147)
at com.sun.xml.internal.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:152)
at com.sun.xml.internal.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:96)
at com.sun.xml.internal.ws.developer.JAXBContextFactory$1.createJAXBContext(JAXBContextFactory.java:98)
at com.sun.xml.internal.ws.db.glassfish.JAXBRIContextFactory.newContext(JAXBRIContextFactory.java:79)
... 25 more
Things I have tried so far:
JAXB classes from Webservice marshalling error
I have no endorsed jars in my JDK folder, so this answer does not apply
The jaxb-impl jar (2.2.11) is coming from camel-jaxb in my app so it seems very contained and not like this answer suggests.
This answer seems to describe the problem well, but the solution they took seems unclear to me.
Problems creating JAXBContext to marshal object as XML
This question seems to be identical to mine, but the solution they ended up going with can not work for my situation (see below)
Netbeans with JAXB Random ClassCastException ..cannot be cast to com.sun.xml.bind.v2.runtime.reflect.Accessor
I tried the accepted solution System.setProperty( "com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize", "true"); which does work. However, setting this property is not an option for me unfortunately in my environment. Plus, it seems like it's a bit of a hack that does not address the real issue (unless I'm misunderstanding it).
I'm about to hang myself with the little rope I have left. What am I missing here?

I hate to answer my own question, but I wanted to make sure the solution I ended up going with was documented clearly.
The root issue was that the jaxb-impl jar brought in by camel-jaxb was conflicting with the JDK 8 provided version.
This answer describes what is happening more clearly:
I encountered the same error when I tried to upgrade JAXB to a newer
version than what came with the JDK. Java encountered two or more
instances of JAXB at runtime and could not decide which version to
use.
In my case, I simply excluded the jaxb-impl that came with camel-jaxb and the application started working correctly.

I ran into this error when trying to run my JUnit tests through Maven even though they passed locally in Eclipse. My solution was to in a #BeforeClass put:
System.setProperty("javax.xml.bind.JAXBContext", "com.sun.xml.internal.bind.v2.ContextFactory");

If you are using spring boot above 2.2.6.RELEASE add this property to your pom:
<glassfish-jaxb.version>2.3.2</glassfish-jaxb.version>
Because in the next versions it changes the java.xml.bind implementation:
Take a look a this pom IE:
https://repo1.maven.org/maven2/org/glassfish/jaxb/jaxb-runtime/2.3.5/jaxb-runtime-2.3.5.pom :
--add-opens org.glassfish.jaxb.runtime/com.sun.xml.bind.v2=java.xml.bind --add-opens org.glassfish.jaxb.runtime/com.sun.xml.bind.v2.schemagen=java.xml.bind --add-opens org.glassfish.jaxb.runtime/com.sun.xml.bind.v2.schemagen.xmlidref=java.xml.bind --add-opens java.base/java.lang=org.glassfish.jaxb.runtime --add-opens java.base/java.lang.reflect=org.glassfish.jaxb.runtime --add-opens org.glassfish.jaxb.runtime/com.sun.xml.bind.v2.runtime.reflect.opt=java.xml.bind

I run into the same issue in test scope. For me adding jaxws-rt runtime jar helped. Note, that I added it for my test scope only. You are not going to do this for prod runtime, since JEE container supposed to has this or other implementation already.
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.2.3</version>
<scope>test</scope>
</dependency>

WebSphere and Axis 1.4 - NoClassDefFoundError

in my application I have to call a webService using axis-1.4 libraries.
With axis-1.4.jar inside my application I get the following error:
Exception data: java.lang.NoClassDefFoundError: org.apache.axis.message.SOAPEnvelope (initialization failure)
This means (I think) that my jar conflicts with other libs in server (anyway I'm using Parent_Last class loading)
If I try to remove axis-1.4.jar from my ear, I get the following:
java.lang.ClassNotFoundException: org.apache.axis.soap.SOAPConstants
Does anyone knows which library is in conflict with axis-1.4.jar?
Thanks

You can easily find it yourself looking in RAD (if you have it) which JAR contains that classes. You can also try creating a shared library and third option: Extracting the classes you need from the library.

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.