I am trying hard to find the cause of a weird JSF error. To do this, I try to debug the source code inside javaee-web-api module where a NullPointerException is thrown during JSF rendering. But I am stuck because the debugger does not show me the source code of that location.
There is a discussion thread that says that javaee-web-api is stripped (no bytecode for methods) and meant to be used only for compilation.
What does this mean? Can someone explain it in more detail? I want to understand why I cannot debug the location where that NullPointerException is thrown. I think this is related to the fact that these JARs are stripped.
Normally, the class files in a jar file will contain information on the line numbers relating to the code in the class - this is called the debug information. A stripped jar simply does not have this information.
You are correct in assuming this is the problem. The stack trace you see won't contain any line numbers relating to the code in the stripped jar. Since the jar is provided by a third-party, there's nothing you can do to get that information.
Related
I have a file called MyFile.java and it contains multiple classes(none of them is public). Note that the file does not contain MyFile class. Apparently Javadoc is not happy about this and it generates a warning saying file does not contain class com.example.MyClass. A few solutions I looked into:
Move classes into their own files. This looks like the proper way of fixing the warnings, but the new files won't obliviously have the source control history, so I am trying to avoid it.
Create empty MyFile class. This is ugly.
Hide Javadoc warnings, preferably per file. There is a high chance that this is not possible.
A few questions that I have:
Why does Javadoc complain? I couldn't find any documentation, please point me to one. I think it is perfectly fine not to have a class with the same name as the file.
Any other suggestions I can look into?
Is it possible to hide warnings somehow? additionalparam="-Xdoclint:none" does not work.
Thank you all in advance
When building with maven from the command line, I encountered this error from maven-javadoc-plugin.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default) on project code-mapping-database: MavenReportException: Error while generating Javadoc:
... error: cannot access DataSourceWrapper
Eclipse IDE reported a similar error.
This occurred after I had copied DataSourceWrapper.java to another (dependent) project and commented out all lines of DataSourceWrapper.java in the original project. After deleting the commented out version, the error went away. The effectively empty DataSourceWrapper.java file must have caused maven-javadoc-plugin to stop looking for class DataSourceWrapper.
Logback 1.1.7
This was during a "production" run: stack trace from Exception (actually NoClassDefFoundError is an Error):
Exception in thread "main" java.lang.NoClassDefFoundError: ch/qos/logback/core/rolling/helper/TimeBasedArchiveRemover$ArhiveRemoverRunnable
at ch.qos.logback.core.rolling.helper.TimeBasedArchiveRemover.cleanAsynchronously(TimeBasedArchiveRemover.java:231)
at ch.qos.logback.core.rolling.TimeBasedRollingPolicy.rollover(TimeBasedRollingPolicy.java:178)
at ch.qos.logback.core.rolling.RollingFileAppender.attemptRollover(RollingFileAppender.java:204)
at ch.qos.logback.core.rolling.RollingFileAppender.rollover(RollingFileAppender.java:183)
at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:224)
at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100)
So I looked at the source: that class ArhiveRemoverRunnable does indeed exist in the .java file where it should have been instantiated on l. 231 (with that mis-spelling)...
Then I unpacked the executable jar (logback-core-1.1.7.jar): again, the file TimeBasedArchiveRemover$ArhiveRemoverRunnable.class exists in the package, as does file TimeBasedArchiveRemover.class.
This error is not going to happen that often: it is obviously when the "rolling" logger decides it's time to clean up the directory.
Anyone got any idea why this might happen? Troublingly I find no evidence of anyone else experiencing this...!
Potential workaround (pending):
I thought the answer to this might be to extract the source files for this .jar, edit the offending class, compile and repackage as an executable jar, and then use instead of the downloaded jar. In order to do this I started a new Gradle project in Eclipse, imported the entire source package, etc. The thing compiles (builds) OK in Eclipse-with-Gradle, with no complaints of the "NoClassDef" type...
But I'm having difficulties actually producing this executable jar. It'd be a nice thing to be able to accomplish: ability to tweak and test a downloaded dependency in some way (if really necessary).
Current not so satisfactory workaround:
In fact I have no need for a "time-based" archive remover. I'm quite happy just having archives removed on the basis of the size of all the files in the logging directory. This answer appears to solve this. However, logback is quite a beast: I'm not entirely sure: is "archive removal" the same thing as "rollover"?
If the Error occurs again, of course, I shall have to make a special utility method to log every LOGGER.xxx command within a try...catch.
I'm debugging a 3rd party proprietary jar. JD-eclipse generates the source just fine but I can't add breakpoints into the generated source code.
Eclipse complains the class file lacks line number info.
Is there any way to work around this?
Unfortunately, there is no workaround. If the original class was compiled without debug info it's lost to you - there's no way you can fabricate it out of the void.
I am working on moving code from R2007a to R2013a. I am getting a java.lang.NoClassDefFoundError during my run in R2013a which does not appear in R2007a. It occurs when I call.
feval('get',fname,jevent);
Where fname is a product.ProxyField object for an Object Filter and jevent is a product.format.java.internal.JavaEvent.
The class is in a jar file on the path and is being accessed by another class in the same jar file. The stack trace does not leave the realm of the product if that helps.
I do not have access to the original code for the jar file. I do have access to code derived from that original code and both classes are in the same package. I'm guessing this has something to do with differences in the java version but I'm not sure what to do since I don't have the original code to recompile.
Unfortunately I can't provide actual source or full detail but a google search only yielded results for MATLAB startup issues. Any thoughts?
Seems like the difference between R2007a and R2013a is that the first uses 1.5 jre and second uses 1.6 jre. It would be easier to help you if you provided the stack trace showing the exception. Sometimes classes get moved around in between jvm versions, so having the actual missing classes would help in determining if the missing class is a class that was just moved around to a different package. You could take the missing class, google it adding the same exception message as you put above and seeing who else ran into similar issues.
I'm currently using Apache Tomcat 5.5.16 to serve a Lucene-based search API.
Lately I've been having some NullPointerExceptions inside my servlet class. The class is called com.my_company.search.servlet.SearchServlet.
With certain types of input I can routinely create a NullPointerException, but I'm having trouble figuring out where exactly it is.
The StackTrace indicates that the bug is occuring here:
com.my_company.search.servlet.SearchServlet.doGet(Unknown Source)
The source and .class files for this class is all in:
$TOMCAT_HOME/webapps/my_servlet/WEB-INF/classes/com/my_company/search/servlet/
My question is, how can I get Tomcat to provide me with more descriptive error locations?
Tomcat cannot provide you more detailed information unless the classes in question were compiled with debugging information. Without this debugging information, the JVM cannot determine what line of code the error occurred on.
Edit: You can ask the compiler to include this information by specifying the -g option when running javac on the command line. You can also specify this option using the debug parameter of the Javac Ant task.
you have to add debugging information to your classes. compile them with the option -g:
javac -g YourServlet.java
the location unknown source can occurs when the JIT compiler has optimized your class. At that point the source information is lost. to get the original location, restart the server and retry your test. Most of the time you will get the location in your source