Project returns error Error 500: javax.servlet.ServletException:
java.lang.NoClassDefFoundError: com/cloudant/client/api/ClientBuilder
But class exists.
Error below (removed project's name).
Here is the dependency
I've already tried an mvn clean install -U, removing the .m2
folder and still no luck so far.
Eclipse version is Version: 2018-12 (4.10.0).
My computer is macOS High Sierra 10.13.6
No class definition found error indicates that your Java runtime could not find the class in question. Please check if your app is deployed to the runtime which you think it should be deployed.
Mostly this would be linked to any of the following steps in you project life cycle.
1. Build (turn on 'build automatically') in Eclipse. I see you've done these steps.
2. Deployment to target runtime (like deploying to some web container). Check if your code is being deployed or not to target runtime.
But I see that you've already mentioned that it works for sometime, which means that you need to understand why the runtime is unable to access your class at that moment. I would do the following.
1. Check if JAR is already present.
2. If not present, follow the build deploy steps you've followed. This means that you'll have to establish how the JAR mysteriously got deleted.
3. If JAR is present, but you see this error, then it means that your runtime CLASSPATH has mysteriously changed and that needs to be investigated. Ideally this should not happen, as all softwares usually are 'consistant', i.e. they either consistently have error or consistently work. This inconsistency itself indicates something environmental which you need to crack.
Is that IBM WebSphere? If this is in your company and it is a shared server or something, check if someone is inadvertently fiddling with your deployment or something.
Good luck!
Edit: Check if this helps you conceptually - NoClassDefFoundError by switching to another project
Related
I'm asking and answering this question to save me from going down this rat hole again in the future.
I'm building a cross platform eclipse IDE based software development environment with about 40 plugins. When I installed the latest nightly build and did some testing on my Linux test system the application started throwing the dreaded java.lang.NoClassDefFoundError when I did a certain action. This was not happening on my Windows installation. It did not happen in my development environments on Linux or Windows. This action and the code behind it is new and so not yet covered in our automated test suite.
The plugin throwing the exception was trying to access a static class method in another plugin, but failing to find the class. Things I tried:
First thought: static initializer fails for some reason! Nope. I can see other plugins access this static class and methods prior to the failure (by attaching my debugger to the installed instance of my product and stepping through the code).
The fact that it works from other plugins eliminate the other usual reason for failure, not properly exporting the package. It was exported correctly.
I poured over my plugin dependency list, comparing them to plugins that were able to access the offending class, but with no success. All dependencies were accounted for.
I did a deep dive into my MANFEST.MF. I switched from using "Required-Bundle" to "Import-Package" in the MANIFEST.MF. That created new problems for me so I reverted that change. Everything looked good.
My build.properties looked good. Not too much in there to go wrong. It was consistent with my MANFIEST.MF where it counts.
I deconstructed my plugin on the installed instance to be sure that the class was indeed present. It was.
Everything was configured correctly. Everything!
I poured over many related SO questions and blog posts but none of them offered a solution that worked or any additional insight into the problem.
The next step was to start iterating over my nightly builds to find the build where the problem first showed up. Once I identify that build, I'd be able to iterate over all the commits from the day before, doing full builds, then installs to find the commit that broke it.
I started 10 days prior and installed every nightly build. All the way up to the build that failed in my test environment. Every single one of them worked. Why?. See my answer below (or submit you own).
When testing a new eclipse IDE build make sure you start with a fresh new non-existent workspace directory and use the "-clean" command line parameter to flush any caches that survive from a previous installation.
The failure was happening because I (1) failed to delete my previous workspace directory before starting the application; and (2) did not use the "-clean" command line parameter to delete related cached information; and (3), even "-clean" may not be enough, I also removed the entire application directory (which, in turn, removed the 'configuration' directory and all cached data within that may not have been "cleaned" by the "-clean" command line argument).
I had been refactoring a few class names to have more meaningful names. When I ran the product with an existing environment the product was using cached data, getting the old name of a class that had been renamed, and failing to resolve it. (You might think that seeing the old name was a good clue, but, unfortunately, one of the first things I tried was undoing the class name refactoring, thus restoring the previous name. So the error reported the correct name, but, I suspect, there is a signature of sorts that did not resolve.)
Of course it is a best practice to always start with a new workspace when testing. I've been doing Eclipse IDE development for years and I know this well. But yesterday I forgot (not helped by the fact that my Windows installation did not suffer the same error for whatever reason). You will forget on occasion...and it will bite you.
I'm aware several people have asked very similar questions to this one, but I really need help finding the solution to my particular case.
Please read and understand this question before posting an answer :)
I'm using
Eclipse (both Juno and Kepler)
JDK 1.7
Tomcat 7
the Sysdeo Tomcat plugin
and in one particular project (other projects are fine), the following happens:
I set a breakpoint
start Tomcat
execution arrives at that point
I get a message: "Unable to install breakpoint on com.foo.bar.Main.class due to missing line number attributes" Reason: Absent Line Number Information
The thing is, if it can't install a break point - why is it stopping at exactly that point in the code where I set the breakpoint? Also, it says line number information is missing but I've verified all Compiler options and even used javap to confirm that line number information is in the compiled Main class file.
Note:
I am not using Ant to build
I am using the 1.7 JDK in Eclipse (not JRE)
Any guidance or suggestions welcomed.
Edit:
Hmm.. further information that may be important. I'm using Spring, and the actual class that Eclipse tells me has no Line Number Information is actually of the form: 'Main$$EnhancerByCGLIB$$87eae52c'
Could it be that a pre-compilation layer is generating classes without line numbers?
Maybe your class files in Eclipse class path is not matched with the class files you have in Tomcat webapp folder. There are out of synchronization.
You can try to deploy newly built war file again.
I have gone through the Question:
[weblogic.application.ModuleException: Context path '' is already in use by the module: / application:
and followed as answer of the question says; but still getting the same exception:
**> Deployment failed. The message was:
weblogic.application.ModuleException: Context path
'/socketss-war' is already in use by the module:
/Socketss-war application: Socketss
D:\NetBeansProjects\Socketss\Socketss-war\nbproject\build-impl.xml:1056:
The module has not been deployed. See the server log for details.**
Any guidance or suggestion would be highly appreciable.
Thank you!
ModualException come due to inproper Bulid.
Go through step by step.
Update project
Restart your eclipse
Remove project from server
clean server and redeploy your project
Now publish it i hope now it will work
Yup. Try to deploy from Netbeans.
The Weblogic eclipse plugin is, in my experience, the worst deployment plugin I've ever seen. If you are using a patched weblogic - such as 12.1.2 with Patch Set Update 6 - your deployment from eclipse might miraculously not work with such an error.
If you are able to deploy the WAR file without IDE by going to the deploy view, I recommend that you try using Netbeans to deploy and see how it goes.
Notice as well that the outcome of trying to deploy from eclipse as exploded war or as virtual application is not the same. Typically both do not work with different exceptions, depending on the patches you are using.
In my case, I have two local installations of weblogic 12.1.2. One with the patch set update and another one without. From eclipse, It is only possible to deploy to the one without. From Netbeans, deployment works regardless of the instance.
I spend one day trying to fix this issue, and finally found a solution. As Google doesn't have any answer for this Eclipse error, I thought of putting this for everyone.
Issue:
When I try to publish project via eclipse, I'm getting this error message:
No runtime specified. WLS Web Service projects require a runtime to be present for most tooling.
How to solve this problem?
(Credits go to Akshay who originally posted this solution in his question.)
This error message appears if your target runtime is not set to the Weblogic version you are using.
The fix is pretty simple, just follow these steps:
Right click on your Project Folder, then Properties
Select Target Runtimes
Once you select you will see the WebLogic version you have added for your project
Just activate the checkbox and hit Apply
Done - your error should be gone
Everything was going well. Nightly builds ran for more than a month with no problems. However, suddenly when invoking the feature builder from Eclipse the execution ends right away with the message.
ERRORLEVEL 13
As far as I know I haven't changed anything, as this computer is normally not touched. (It is only used for the nightly builds).
I've googled around to see what this error means but to no avail. I found a link from IBM that shows a custom bat file that catches this error, but the explanation given is not very useful.
My guess is that this is related to the workspace, somehow, or that the whole eclipse installation is corrupted.
Do you have any idea what this error means and how can it be corrected?
After reading what the error code means thanks to the answer from VonC I understood where to look. The problem was a lot more obscure that it seems.
I looked into the configuration folder for Eclipse (logs are either written there or in the .metadata folder when something goes wrong), and I found a huge log file. Inside the file I found the following error:
application org.eclipse.sdk not found
and the following exception, followed by a plugin name, several times:
java.util.zip.ZipException: Too many open files
Several plugins could not be loaded, causing a cascade of missing dependencies that prevented Eclipse from launching. I searched the web for this exception and found the following bug description from SUN, which says that Java 1.5.0 can not open more than 2,100 zip files.
The problem started a while after I installed the BABEL project translations for Eclipse into the build computer. These are more than 900 fragments, containing translations for many plugins, one for each language. As I installed it on top of an existing eclipse installation, it seemed that it was not a problem to open them.... until I cleared the workspace for the builds. Then Eclipse wouldn't launch anymore. I went over the limit. It didn't help that the first thing I tried to fix the build was, again.... clearing everything.
Because I only use this computer for headless builds, I didn't realize that the problem was in Eclipse itself and I was looking inside the build process. I only realized when I looked into the log file.
After installing Java 1.6.0_11 I was able to launch Eclipse and go on with my build.
It should mean "ant build failed", meaning the headless ant script fails at some point.
You should check if you can catch the log/output generated by this script to analyze this ant session and see at what point the ant script fails.
If it fails right away, it usually is because of:
a change in rights (writing access), or
in environment variable modifications, or
in resource access (path non accessible).
You also have to check if the computer is still in its original windows domain, and if the rights (admin ?) associated with the account running the ant script are still the same.