I have a class path problem and would like to know how approach debugging.
The problem is
java.lang.ClassNotFoundException: org.springframework.http.client.AbstractBufferingClientHttpRequest
but I understand AbstractBufferingClientHttpRequest is in spring-web (http://forum.springsource.org/showthread.php?110684-Where-can-I-download-AbstractBufferingClientHttpRequest-jar), which I do have via maven - I see spring-web-3.0.6.RELEASE.jar in the tomcat web-inf/lib directory.
Dont understand why the class is not found, or worse, how to track the problem down.
Google found the process of getting and unpacking the classpath, using java.lang.System.getProperty("java.class.path"); But this does not include anything that maven has pulled in.
What are my debugging options? Where can I learn more about debugging classpath problems?
The environment includes: MyEclipse for Spring 10, Spring Webflow app, tomcat server, maven, Ubuntu OS.
Related
I'm trying to add JSTL support to an spring boot application, but I'm getting this error message when running it from within eclipse:
The absolute uri: [http://java.sun.com/jsp/jstl/core] cannot be resolved in either web.xml or the jar files deployed with this application
If i generare an executable war and run it, JSTL works correclty.
I've tried almost all the solutions described in the other questions but none of it seems to focus on running it from eclipse.
I've created this tiny repo to demostrate it:
https://github.com/rroman-encora/brokenjstl
This is my setup:
Spring Boot 1.5.7
Eclipse Version: 2021-03 (4.19.0)
JDK 11.0.11
The project runs with source and target java 1.8
Thankyou
If another poor soul finds him self in this situation, may this be the answer:
Just copy all the *.tld files from the jstl jar inside your WEB-INF directory and this should work.
Obviously there's a "proper" way to do this, maybe it's just a setting on spring boot, maybe you need to configure the embedded tomcat/jasper TLD Scanner, but today I'm so tired to keep looking for the perfect aswer.
BTW this also keeps working if you deploy your application as an excecutable war.
I was trying to start learning about Apache Wicket (as it looked like an easy to use UI for Java) and as I like to work with Eclipse and Maven. I also like to work with Tomcat, however, Wicket seems to prefer Jetty at least in its tutorials. I do not know nothing about Jetty, however should not take ages to learn.
I tried the Wicket Quick Start and successfully imported the generated Maven project to Eclipse workspace.
But errors appear: e.g.
import org.eclipse.jetty.server.HttpConfiguration;
It seems Eclipse cannot find the jetty server classes. How to add these to the Eclipse project?
Does the creater of the Wicket Quick Start assumed that Jetty is already installed on the machine?
I installed it. However: what is the recommended way to make what jar file available to a maven project to have jetty server classes available? I would assume via the pom.xml but I doubt that is the case here - the given pom.xml would contain it.
Or is there some special plugin for Eclipse (Photon)?Run-Jetty-Run?. I wasn't brave enough to try that.
I would love to get the Wicket Quick Start running.
I also tried Eclipse + Tomcat + Apache Wicket Maven Setup with Hello World Example but it seems that it is outdated. I was not able to install qwickie to Eclipse as described.
I am using Eclipse Proton with Java 10.0.2 on Debian Stretch.
If you are using https://wicket.apache.org/start/quickstart.html then you can start the application these ways:
mvn jetty:run - this will use jetty-maven-plugin
Open in Eclipse src/test/java/com/example/Start.java and run it as a normal Java class with a main(String[]) method. This will use Jetty Maven dependencies to start an embedded Jetty server.
Wicket's Quickstart prefers Jetty because Jetty developers made it easy to use it in non production way, i.e. in development mode, for faster dev cycles. No need to build a .war file and deploy it.
On the other side Tomcat devs (disclaimer: I am a member of both Wicket and Tomcat teams) never spent time in this direction. Tomcat's Maven plugin has been abandoned long time ago. The best integration for starting embedded Tomcat is provided by Spring Boot project (I recommend it if you use Spring!).
So, just remove the Jetty related dependencies and plugin in pom.xml and the Start.java in src/test/java/.... Then you can continue developing with Eclipse and Tomcat the way you like to do it.
i have written an application on my pc using CDI as the backing bean for jsf, the application works completely fine.
Now i setup everything on a new pc, installed glassfish 4.1, setup eclipse kepler by putting the installed jre as jdk7 from the glassfish folder.
when i make a war for the application on my pc and deploy it onto the glassfish server on the other pc everything works fine.
now i tried taking the project from my pc and imported it onto the new pc. the eclipse on the new pc wont recognize import javax.enterprise.context.SessionScoped; giving compiler error that this annotation is not available.
The import javax.enterprise.context cannot be resolved
it doesnt recognize javax.enterprise.context.* at all. like CDI is not available. i am using JDK 7 which contains JSR 346, so i am completely confused what the issue could be.
if i deploy the application directly through the glassfish admin console using the war file it works perfectly fine but if i try to publish it through eclipse, it gives me unresolved compilation errors
Eclipse did not import ALL glassfish jars, so you need to:
Right Click on the project name, Build Path, Configure build path, under Libraries Click Add External Jars, go to where you have extracted Glassfish and import all jars that exists in:
glassfish4\glassfish\modules
and all sub directories two, like endoresed.
This will fix the problem for CDI and other stuff lik JAX-RS
If I had to guess, your .project and .classpath files are pointing to JAR locations that are specific to your old computer.
This is why people like build tools such as maven, or gradle, you can pick up and reimport a project; it'll resolve all dependencies for you.
Do you happen to use the GlassFish Tools plugin for Eclipse? I found that the GlassFish System Libraries classpath container, which is created implicitly by that plugin and which is added to all projects that specify a GlassFish server as their runtime, misses cdi-api.jar. This is where the javax.enterprise.context.* package is located (and many others).
So I could fix this by adding cdi-api.jar as an External Jar to the build path. After that, you may get a warning like Classpath entry [...]/cdi-api.jar will not be exported or published. Runtime ClassNotFoundExceptions may result., which can be eliminated by using the Quick Fix to Exclude the associated raw classpath entry from the set of potential publish/export dependencies. That JAR file is already contained in the modules folder of GlassFish, obviously.
Maybe this problem only occurs with the GlassFish Web Profile, at least that's what I use.
I am getting the following error:
java.lang.NoSuchMethodError: org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator(Ljavax/servlet/http/HttpServletRequest;)Lorg/apache/commons/fileupload/FileItemIterator
though I have added commons-io 1.2 jar and commons-Fileupload 1.2.1 jar in my buildpath.
Please help me out.
There is probably an incompatibility between the file-upload version you're using and the servlet.jar you have on your server.
I can't tell you if it is between the "commons" jars or between the server jars and "commons".
Anyway, I suggest you use a maven (or gradle even better) project at least to get your jars in a consistent way. If your project is not ready, you can still pack your application as a war and get the correct jars from the zipped output fil of your maven compiling.
I have a custom classloader jar <scope>provided</scope> that must be in tomcat/lib before my webapp is run or else it fails to start. I'm using WTP. Is there some way that I can configure M2E/WTP to automatically copy this custom jar to tomcat/lib during the deploy process?
Edit:
It doesn't have to be using WTP, I could also use, for example, a solution using tomcat6-maven-plugin.
For running an embedded Tomcat instance with the Tomcat Maven plugin, add the JARs required in the Tomcat lib dir as dependencies of the Tomcat plugin itself as shown in this example with the derby and javamail dependencies.
I spent a lot of time researching this problem and here's what I've found:
The tomcat6-maven-plugin does not properly emulate the tomcat boot order, as seen in this jira issue as well as their tomcat6-maven-plugin source.
However, after more research I discovered another maven plugin that I didn't know existed: cargo. Thanks to their excellent documentation I was able to get my project running with the custom (and picky) class loader jar.