Question

org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: java.lang.NoSuchMethodError: org.mobicents.protocols.ss7.sccp.parameter.SccpAddress.<init>(Lorg/mobicents/protocols/ss7/indicator/RoutingIndicator;ILorg/mobicents/protocols/ss7/sccp/parameter/GlobalTitle;I)V

The odd thing is that I run on the same set of Mobicents Protocol JAR libraries on the development machine, but I receive this on the server.

The line causing the problems is:

SccpAddress localAddress = new SccpAddress(RoutingIndicator.ROUTING_BASED_ON_DPC_AND_SSN, Controller.LOCAL_SPC, localGT, Controller.SSN_CAP);

And is very similar to the one used in their test cases. I received the same error when I tried that line verbatim as well.

I received the same error when I tried using the decode method in SccpAddressCodec, with a valid byte array.

I’m using the version 1.0.0.CR1 of the Mobicents SS7 Protocols stack.

Answer 1

There are a half-dozen or so different reasons for NoSuchMethoError. One common one occurs when you compile against version 1.2, say, of a JAR file but then run against version 1.1, and there is an incompatibility between the two versions. This can happen with the simplest of calls.

Slightly more complicated are some scenarios surrounding interfaces. It’s possible (through some oddball paths) for a class to implement an interface that it does not support all the methods for, and going down path A or path B in the same code (with the same JAR files) can provoke the behavior or not. These are a bear to sort out.

But I’d first look at the JAR files present in the two environments and see if they’re different. In general (there are exceptions) you should always try to use the oldest/lowest version JAR files in your compilation environment. (Which is a problem, of course, since the compile environment always tends to have the latest stuff.)