This blog will speak about how did I debug and fixed the AbstractMethodError issue (https://issues.apache.org/jira/browse/ZEPPELIN-1025) on providing incorrect input for the Zeppelin interpreter REST API.When I started with the ticket, I thought it would be simple enough to fix but it was time consuming in figuring out the cause and fixing it.This read will help you with some of the tips which could be used to resolve these kind of issues if you come across.

When I started debugging the issue I misunderstood the error with NoSuchMethodError and after realizing that it is different from what I thought, I tried to reproduce the issue locally.Then I found that the actual cause of the issue is due to calling a method of javax.ws.rs.core.ResponseImpl which wasn’t implemented.The stacktrace showed that some class in Apache CXF related jar tries to invoke the method in ResponseImpl which was included in the same jar and implemented but somehow another verison of ResponseImpl from some other jar was actually being invoked.

I was able to find out the actual jar where the call is being made with the help of STS (Spring Tool Suite) and it was due to Jersey version 1.0 jar.There was a similar implementation of ResponseImpl in it and it didn’t implement the method being invoked.Then I continued with fixing the issue and it also took considerable time to look out for the solution.

I tried with various ways to fix it and one of them is to upgrade Jersey to version 2.0 This turned out to require more time since there were lot of internal zeppelin dependent jars which were using Jersey 1.0 jars and there was also a local repository maintained with the zeppelin module for the notebooks which in turn had the Jersey jars.After upgrading them to the latest Jersey version 2.0 there were other issues w.r.t to the ServetContainer class used in the application context from the older Jersey version.Even after fixing them, it lead to other issues at run time on navigating through the features in the product.

Then finally find out that both CXF and Jersey jars shouldn’t be used together since there were duplicate implementation of classes in both.In the meantime, I found that there was already work done by another person in the community to remove CXF and upgrade Jersey 1.0 with Jersey 2.0 When I tried to apply the changes made relevant to it the issue got resolved.

This let me made to learn to use STS in order to reproduce the issue and figure out the actual cause of it.Also, knowing what was happening in the open source community helped me to not waste my time in fixing the issue which was already done by another person.