I'm facing this issue for the first time, here's the exception that gets thrown in the service
Exception in thread "Thread-1" java.lang.NoSuchMethodError: org.codehaus.jackson.type.JavaType.<init>(Ljava/lang/Class;)V
at org.codehaus.jackson.map.type.TypeBase.<init>(TypeBase.java:13)
at org.codehaus.jackson.map.type.SimpleType.<init>(SimpleType.java:45)
at org.codehaus.jackson.map.type.SimpleType.<init>(SimpleType.java:40)
at org.codehaus.jackson.map.type.TypeFactory._fromClass(TypeFactory.java:374)
at org.codehaus.jackson.map.type.TypeFactory._fromType(TypeFactory.java:434)
at org.codehaus.jackson.map.type.TypeFactory.type(TypeFactory.java:61)
at org.codehaus.jackson.map.ObjectMapper.<clinit>(ObjectMapper.java:174)
at com.kx.proto.validation.util.Common.<clinit>(Common.java:41)
and once this exception is thrown, the service stops receiving the subsequent api calls made to the service ( even though i have caught the exception ) , pod is still in running state.
I'm curious about two things here
The exception that gets thrown, how to fix that ? Change in POM file?
Why would the exception that has been caught would stop service from receiving further REST api calls. Basically after the exception , all the apis in service start timing out.
Below is the piece of code where exception gets thrown
at this line
GeneratedMessageV3 messageV3 = Common.loadDefaultObjectFromMessage("com.kx.proto.", recordId.toUpperCase() + "Record");
and here's the loadDefaultObject from message method
public static GeneratedMessageV3 loadDefaultObjectFromMessage(String pkg, String messageName) {
try {
Class<?> record = Class.forName(pkg + messageName);
Optional<Method> getDefaultInstance = Arrays.asList(record.getDeclaredMethods()).stream().filter((method) -> {
return method.getName().equals("getDefaultInstance");
}).findFirst();
if (getDefaultInstance.isPresent()) {
Object obj = ((Method)getDefaultInstance.get()).invoke((Object)null, (Object[])null);
return (GeneratedMessageV3)obj;
}
} catch (ClassNotFoundException var5) {
System.out.println("class not found " + var5.getMessage());
} catch (Exception var6) {
var6.printStackTrace();
}
return null;
}
NoSuchMethodError is an Error (not an Exception) that occurs when the classpath during compilation differs from the classpath at runtime.
It says: I could find that method during compilation, but I can't find that method now at runtime.
It typically occurs when the runtime classpath differs from the compilation classpath. This gets more complex if your project A depends on jar B which depends on jar C. Presume all three projects (A, B and C) are compiled/released at a different time.
Start with doing mvn dependency:tree on your project. Ask the verbose version of that. One typical cause is dependency versions overrides with a lower version. For example your project A depends on C 1.2 and B 3.0 but B 3.0 depends on C 1.4. What if B was compiled using a method of C that only exists since C 1.3? When B is run in project A with C 1.2 instead of C 1.4, it doesn't find that method and NoSuchMethodError is thrown.
Note: there is an enforcer rule to enforce not downgrading transitive dependencies. It's very useful to avoid such surprises at runtime.
Related
I'm sure I'm doing something wrong here with dependency management, but can't quite figure it out.
My Maven project "A" is dependent on project "B" (a gradle managed project). Both "A" and "B" also have a dependency on Selenium for UI automation. "B" is a collection of some selenium processing libraries. The selenium webDriver object is initialized in project B and returned to A, like this:
Some class in project A:
public WebDriver myDriver;
myDriver = B.initializeWebDriver(myDriver, various selenium related parameters...);
Then "A" can utilize the initialized myDriver object in a testNG test.
The place where it crashes in "B" with no stack trace is:
initializeWebDriver method in project B:
public WebDriver initializeWebDriver(WebDriver webDriver, ...) {
webDriver = new RemoteWebDriver(new URL(url), cap); // <-- crashes here
return webDriver
}
I would have thought that "A" and "B" would simply need to have a dependency on "selenium-java". That's all "B" has as a selenium dependency, and can create the driver and use it in various unit tests wholly contained in project B. If project A has a dependency on selenium-java, and I run a test from A, then Java immediately ends the testNG test when it reaches the line of code in "B" that instantiates the remoteWebDriver. I have a try-catch in both A and B, and nothing ever happens. No stack trace. No log message. Just immediately dies inside the test method in A, not jumping to a 'catch', but jumping to the 'finally' and ending.
What makes me pretty sure it's a dependency management problem, is that if I change the dependencies on "A" to selenium-api and selenium-chrome-driver and selenium-remote-driver, it works fine. But we shouldn't need to do that -- selenium-java should be fine, and selenium-java contains those other objects (selenium-api, etc) anyway! I'm guessing it's some weird CLASSDEF problem and I'm not doing dependency management correctly. I've also never seen java just blatantly give up with no stack trace or errors like this, unless it's some really weird classdef thing.
Any ideas?
**
[Edit: additional code provided as requested]
From B:
public WebDriver getWebDriver(WebDriver webDriver,...) {
try {
System.out.println("inside B try");
webDriver = new RemoteWebDriver(new URL(hubUrl), cap);
System.out.println("B instantiated webdriver");
} catch (Exception e) {
System.out.println("Caught in B");
e.printStackTrace();
}
return webDriver;
}
From class in A:
try {
System.out.println("inside A try");
webDriver = B.getWebDriver(webDriver);
System.out.println("webdriver A successful");
} catch (Exception e) {
System.out.println("caught in A");
e.printStackTrace();
} finally {
closeBrowser(webDriver);
}
Output from this is:
inside A try
inside B try
then output from the closeBrowser routine from the 'finally' in A.
No evidence of any exceptions or anything caught. As soon as it hits the line in B to create the remoteWebDriver, it just dies somehow with no output, and goes to the 'finally' in A.
Edit: Fixed the problem, I had the gradle project 'B' ensure that it was including the selenium dependency in the .jar it was exporting for project B:
from sourceSets.main.output
from sourceSets.main.allJava
... and in Maven project A, I defined the dependency on selenium-java (removed all the other various selenium jars like selenium-api, etc as this works now) as scope:provided.. So it's ensuring that the selenium-java dependency is in fact truly acquired from project 'B'.
But I don't understand why I couldn't have A and B both be dependent on selenium-java. They were specifying the exact same version, and I looked at the dependency resolution and they both were truly using the same version, as opposed to using a different version due to some conflict of some kind.
[edit]
The order of the dependency listed in project A's POM file is what made it work, not the gradle change or the 'provided' change. Simply listing selenium-java first in the pom before project B.
I don't know why you are not getting a stacktrace. Perhaps you are terminating the program in your closeBrowser method? That would short-circuit the error and would explain why you are not getting uncaught exception stacktrace.
Anyhow, for debug purpose, try the following:
You are catching Exception, so Errors are ignored.
Change your try-catch to catch Throwable. This will ensure you catch any possible errors.
try{
...
} catch (Throwable e) {
System.out.println("caught in A");
e.printStackTrace();
}
I had a strange problem today... I'm going to make a simplified example since it "worth a thousands words" :D
public class Application() {
public static void main(String[] args) {
try {
A a = new A(); // this may throw exceptions
// (which will cause an ExceptionInInitializerError)
} catch (Throwable t) {
JOptionPane.showMessageDialog(null, "Oooops!");
System.exit(1);
}
}
}
Since it's a stand-alone application with a Swing GUI, my goal is to give a message to the user in case of any problems (in this case at startup)... the code above works in Eclipse IDE but when I export the project as executable jar by double-clicking on it, well, it just won't open.
So I try to execute it in cmd with java -jar application.jar and it prints in the shell that there was an ExceptionInInitializerError.
Why the error was not caught?
It doesn't work even if I specify catch (ExceptionInInitializerError e).
EDIT:
After more indepth debugging, I found out that this problem only happens when two particular exceptions occur and the latter occurs in the catch block of the former.
I corrected the bug by changing the order of some checks that I do on startup.
The problem btw should never happen since it was originated by a volountary mistake of the JDBC driver class name to load in a static block.
Well, at least it made me clearly understand why constructors and static initialization blocks should not throw exceptions: it makes debugging almost impossible in the case in which the class that throws the exception is used by many classes, since it may become very hard to find out when the class is loaded.
I can think of three possible explanations for an ExceptionInInitializerError not being caught in your example:
It could be being thrown by JOptionPane.showMessageDialog(null, "Oooops!");
It could be thrown before main is called.
It could be thrown on a different stack.
In fact, I think that the 2nd one is the most likely, as ExceptionInInitializerError is thrown when some unchecked exception is thrown (and not caught) during the initialization of a class. That could well be happening before you enter the try block.
I have some Scala code like this:
class Callee {
#throws(classOf[MyCheckedException])
def doStuff() {
}
}
Calling it from Java like so:
public class Caller {
public static void main(String[] args) {
// this won't compile; the Java compiler complains that the catch block is unreachable
// however without the catch block, it complains "unhandled exception MyCheckedException"
try {
new Callee().doStuff();
}
catch (MyCheckedException e) {
}
}
}
Removing the catch block results in an error from the Java compiler saying 'unhandled exception type MyCheckedException'. Adding the catch block for MyCheckedException results in the compiler complaining about the catch block being unreachable, because the exception is never thrown.
If I catch Exception and do an instanceOf, I can trap the correct exception coming out of doStuff, but I thought the #throws annotation was supposed to generate the right bytecode for the proper catch block to work. Am I wrong, or is there a bug here?
For the record, this is with Scala 2.9.2 and Java 1.6.
Edit: It compiles fine invoking javac/scalac using sbt from the command line. The error is only apparent during compile-as-you-type in Eclipse, which suggests the bug is in either the Eclipse Java Compiler or some part of the IDE. Can others reproduce it this way? I am using Eclipse 3.7.2
I can reproduce this on Helios with 2.9.1. It is a bug in the presentation compiler, and you should raise it as a bug on http://www.assembla.com/spaces/scala-ide/tickets.
For future reference, this issue has been fixed (https://github.com/scala-ide/scala-ide/commit/055a81cd3fe792e4327668791888c30cf04793f5). The fix is already available with both Scala IDE 2.0.x and Helium nightlies.
Furthermore, it will be included in the next Scala IDE 2.0.2 maintenace release.
(sorry for the additional noise, but I realized that having an answer was more visible than a simple comment)
I'm trying to open an URI with Swing that I get above error.
What is the reason and how can I fix it?
When I do it in console everything is OK but when I do in GUI I get this error.
I should say that I use Weblogic as server.
Code
private static void open(URI uri) {
if (Desktop.isDesktopSupported()) {
try {
Desktop.getDesktop().browse(uri);
} catch (IOException e) { /* TODO: error handling */ }
} else { /* TODO: error handling */ }
}
Stack trace:
Exception in thread "AWT-EventQueue-1" java.lang.NoClassDefFoundError: java/awt/Desktop
at be.azvub.ext.bcfidownloder.BcfiDownloadPanel.open(BcfiDownloadPanel.java:230)
at be.azvub.ext.bcfidownloder.BcfiDownloadPanel.access$000(BcfiDownloadPanel.java:37)
at be.azvub.ext.bcfidownloder.BcfiDownloadPanel$7.actionPerformed(BcfiDownloadPanel.java:147)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.Component.processMouseEvent(Component.java:5517)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3129)
at java.awt.Component.processEvent(Component.java:5282)
at java.awt.Container.processEvent(Container.java:1966)
at java.awt.Component.dispatchEventImpl(Component.java:3984)
at java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3819)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
at java.awt.Container.dispatchEventImpl(Container.java:2010)
at java.awt.Window.dispatchEventImpl(Window.java:1791)
Doc on NoClassDefFoundError
The searched-for class definition existed when the currently executing class was compiled, but the definition can no longer be found.
You do have some incorrect classloading happening. Mostly due to wrong class loader chaining.
NoClassDefFoundError can only be caused by a classpath problem.
Because Desktop is part of jre, make sure that your classpath contains a reference to the jre library.
In Eclipse, you can go to run configurations --> Classpath and check there
UPDATE:
As Andrew suggested, you can also check you have at least java 1.6
java.awt.Desktop has been introduced in Java 6. Chances are high you're running your code on different JRE versions.
I'm strugelling with an odd problem for days now.
Only one of the users of my webapp get an NoClassDefFoundError when trying to use some functionallity. This is the stacktrace:
java.lang.NoClassDefFoundError: com/sun/xml/bind/WhiteSpaceProcessor
at com.sun.xml.bind.DatatypeConverterImpl._parseInt(DatatypeConverterImpl.java:105)
at com.foo.bar.webservice.generated.GetLoginsRequest_JaxbXducedAccessor_panelId.parse(TransducedAccessor_field_Integer.java:32)
at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.startElement(StructureLoader.java:166)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:406)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:384)
at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:35)
at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:101)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:224)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:107)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:289)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:272)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:106)
at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:424)
On a strange way WhiteSpaceProcessor can't be found while it is on the classpath.
I used tattletale to look at the possitions of the usage of the classes:
WhiteSpaceProcessor only exist once on the classpath:
DatatypeConverterImpl only exist once on the classpath
I'm stuck on the fact that the exact war on a different environment is working perfect.
working environment:
Windows machine
Tomcat 5.5.28
Java 5 (jdk1.5.0.22)
none working environment:
Linux machine
Tomcat 5.5.??
Java 5 (jdk1.5.0.22)
I hope somebody can sent me in the right direction.
tomcat server is already restarted
Did you use tattletale on the working or non-working machine?
Perhaps the failing environment contains some jar file in jre/lib/ext (or a similar extensions directory), and that's being used in preference to a "lower down" version?
EDIT: Just to go into a bit more detail about the situations in which NoClassDefFoundError can be thrown, it's worth reading the JVM spec, chapter 5. It talks about three situations:
The resource corresponding to the class can't be found at all
The resource is found, but doesn't correspond to the right class (although in that case I'd expect a message including "wrong name")
You're using a version of Java earlier than 1.2, and the class file has an unsupported major/minor version number. (This situation now throws UnsupportedClassVersionError.)
Also read section 2.17.5: it states that if the class is in an "erroneous state" (e.g. previously initialization failed, or there was a bytecode verification failure) then NoClassDefFoundError will be thrown.
Now, if the static initializer of the class fails then the first caller sees an ExceptionInInitializerError - but the second caller sees NoClassDefFoundError. Here's a short but complete program to demontrate this:
class Foo {
static {
if (true) {
throw new RuntimeException();
}
}
static void foo() {
}
}
public class Test {
public static void main(String[] args) {
try {
Foo.foo();
} catch (Throwable t) {
System.out.println("First exception: " + t);
}
try {
Foo.foo();
} catch (Throwable t) {
System.out.println("Second exception: " + t);
}
}
}
Now unless something in your system is suppressing the ExceptionInInitializerError, I'd expect to see that in the log before NoClassDefFoundError if that were the problem. I still think it's more likely that your failing system is loading one class in an extension classloader which then can't find the ShiteSpaceProcessor class.
NoClassDefFoundError does not mean that the class file cannot be found in the classpath. It means that the class cannot be loaded. This is generally due to an error during initialization, or, more often, a version mismatch in JAR files on which the class depends.
Eg, you probably compiled against XYZ package version 1.2 and your user has XYZ version 1.1 installed.