This question already has answers here:
Servlet returns "HTTP Status 404 The requested resource (/servlet) is not available"
(19 answers)
Closed 2 months ago.
I know that there are previous questions that ask the same but I still couldn't find the right solution. I am getting: The origin server did not find a current representation for the target resource or is not willing to disclose that one exists. I am using a Tomcat server.
Could someone please help me, the following is my project structure:
.
I was stuck into this problem for a month.
Finally, I figured out that in Eclipse, "Build Automatically" was not set, and I was trying to run my servlet.java file without any servlet.class file, since I wasn't building my project.
The thing which worked for me is to
first build the project => restart the server => run the server on
servlet.
Hope it helps!!
I was running into a similar problem, where my package name was wrong. I fixed the package name and fixed the problem.
Please check your configuration snippet in the web.xml file.
Also, for a cleaner structure, you can create a new folder "jsps" under WEB_INF and move the .jsp files into the same.
The following scenario is explained with the name of the project as abcd, and the port as 8080. The folder WebContent will be inside folder abcd.
In application.properties, add your path
upload.path=C:/.........../abcd/WebContent/
If the last slash after WebContent is ignored, then uploaded files are saved at abcd and not in WebContent (which is inside abcd).
Now, say, there is 1.JPG inside WebContent. If I have to access it, then in my browser ,I have to put URL as http://localhost:8080/abcd/1.JPG
Having the URL as
http://localhost:8080/abcd/1.jpg wont work (note the small case alphabets of .jpg)
Also make sure that the file 1.JPG is visible inside WebContent in abcd in IDE (in my case, it was Spring Tool Suite). Else refresh the project from the IDE.
Now, if the file 1.JPG is inside abcd/WebContent/new/1.JPG, then the URL will be http://localhost:8080/abcd/new/1.JPG
I faced this issue once when there was a runtime exception in the code block of ContextLoaderListener.
public class YourApplicationContenxtLoaderListener extends ContextLoaderListener{
#Override
public void contextInitialized(ServletContextEvent event){
/* There should not be any exception/error in this block , as it would impact the context initialization by tomcat server for respective war file. */
}
}
I encountered this problem on an Azure WebApp running on Java 11 and Tomcat 9.0.
I changed the Java Web Server version from Apache Tomcat 9.0 (auto update) to Apache Tomcat 9.0.20, and then the server worked.
here is the solution for your query,
Simply follow these steps:
go to project properties settings
type demployment and assembly settings
then click on add folder then and add the webcontent folder to your project,
click apply and close then run the project
I hope your problem will be solved.
Related
This question is related to my question
Jetty 11.0.11 - 404 on html file in \src\main\webapp\static - maven embedded fat jar
What --EXACTLY-- does "jar:file" mean as a Java resource reference, vs. just "file:"?
And how is that influenced by the operating system ran under?
E. g. using this resource reference in Jetty webserver, in Windows with Oracle JDK 17, files are found as resources and parsed by Jetty webserver:
file:///D:/Projects/verdi_2/target/classes/static/,AVAILABLE}{file:/D:/Projects/verdi_2/target/classes/static}
Using this resource reference in Jetty webserver, in Ubuntu Linux 20.04 LTS with Oracle JDK 17, NO files are found and nothing can be parsed by Jetty webserver:
jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static
Is there a difference in how a Linux version of JDK interprets "jar:file" vs. how a Windows version of the JDK interprets "jar:file"?
EDIT: The related issue is the Jetty webserver apparently can no longer serve resources directly out of a JAR file it is itself embedded in. This is now a GitHub bug ticket at https://github.com/eclipse/jetty.project/issues/8549
file: is the beginning of a general file url. jar:file: is that for a jar file particularly, with a view to referring (usually) to a particular entry in a jar. Here's an example you can run (obviously with your own jar url) where you can save an entry as a file (given by the parameter to the app)
import java.nio.file.Paths;
import java.nio.file.Files;
import java.net.URL;
public class JarUrl {
public static void main(String[] args) {
try {
URL url = new URL("jar:file:root.jar!/root/a/b.txt");
Files.copy(url.openStream(), Paths.get(args[0]));
}
catch(Throwable t) {
t.printStackTrace();
}
}
}
What --EXACTLY-- does "jar:file" mean as a Java resource reference, vs. just "file:"?
You're mischaracterising the URL a little bit. The string until the first : decides the 'scheme' of a URL, so, the pertinent question is: How does jar: work. The file: part is a smaller aspect of a sub-part of the jar bit.
How does jar: work
The format is jar:(URL-of-jar)!(path-inside-jar)
Where URL-of-jar is itself a valid URL (and file: is just one way to do that. So is http, for that matter), and path-inside-jar is not a URL but a path.
The meaning is: First, resolve the 'URL-of-jar' URL. This gets you a jar file. Then, open the jar file, and retrieve the resource at the stated path.
So, to pull this one apart:
jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static
The jar is located at URL file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar and the resource it is referring to is the /static resource inside the jar found at the given URL.
How does file: work
That's not java-specific; file: is a generally available URL scheme. You can even type it in a web browser. The more general URL formatting scheme is scheme://server/resource, but with file:, server doesn't apply (it is by definition local to the system you are on), so usually its put as file:///foo, i.e. - an empty 'server' part. Because 3 slashes is a drag to type, I guess, file:/resource is allowed by some 'URL parsers', including java's in this regard, so, file:/usr/... simply maps straight to a local folder: /usr/src/verdi/verdi-12-JDK-etc, as in, if you type ls /usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar on the command line on your system, it would show a result (and if it does not, this URL would fail to find anything).
And how is that influenced by the operating system ran under?
It isn't. file URLs are a general concept that work on any platform. Of course, /usr/src/verdi/etc is never going to work correctly on a windows platform. Or on anybody else's machine. The problem isn't "Oh no! This won't run on another OS!". The problem with file URLs, especially absolute ones, is "Oh no! This will not run on any machine other than this one!".
file:///D:/Projects
I've explained the triple slashes earlier. This is the standard windows 'scheme' for how to stick paths in file URLs: Always forward slashes (even though windows normally uses backslashes), and treat the disk letter as if it is a 'drive' in the 'root': /D:/Project is URL-ese for:
D:
cd \Project
There is no difference in OS at all - file: URLs are handled by 'interpret this file URL the way any file URL would be interpreted on this machine'.
The answer to the related question
Jetty 11.0.11 - 404 on html file in \src\main\webapp\static - maven embedded fat jar
which prompted this post is in the long series of posts beneath this GitHub issue for jetty:
https://github.com/eclipse/jetty.project/issues/8549
In essence, eventually I had to first clean up my Maven pom.xml (see this thread for the discussion and for links to a pom.xml example that is compliant with Maven Shade plugin and Jetty 11.0.11 requirements and standards) then at the end of the day hardcode a link to the JAR file to find the HTML, JS, etc. resources Jetty was to serve out as a webpage. Also put in a conditional where, on compiling, I need to specify if the code will run "in-IDE" (in my case, Netbeans 14) or "in-JAR" - e. g. in a detached JRE elsewhere than the Netbeans 14 IDE.
Also dropped using the Jetty WebAppContext class and started rendering web content out of a normal ServletContextHandler.
Hopefully this may help someone upgrading Jetty from Jetty 9.xxx to 11 and finding that it all falls apart.
For details as to why they changed so much, see the GitHub link (the last few entries are apropos.)
The github discussion also contains full working source code (startJettyc method) that solved the issue of getting a 404 in a detached, non-IDE modality where the JAR was being run in an JRE separate from an IDE.
Stefan
I'm new to Java. I make my first servlet in Intellij Idea 2018.2.1.(in this screen my idea project) I do as instructed from here:
http://www.ntu.edu.sg/home/ehchua/programming/java/javaservlets.html
I created all the directories, as it says in the tooltip, created and compiled the class HelloServlet.java and put it in the desired directory (in this screen my my Tomcat directory with my class), created and filled the web.xml filehere my web.xml and it's Tomcat path. But when I try to call it in a browser string "http://localhost:8080/helloservlet/sayhello" (as stated in the instruction) I get an error in this screen.
What am i do wrong? What i need to do to solve this issue?
Problem is solved. Unfortunatelly, i understand wrong my instructuion, i need to put HelloServlet.class in this path "C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\helloservlet\WEB-INF\classes\mypkg", no this file - HelloServlet.java. Now all works correctly. Thank's to all.
I created a maven project which is bundle in Apache ServiceMix now.
Now i want to add html file to this project and print somethink on it.
How to do it? I try do this but when i want to open index.html i got an error:
URI u = new URI("/MyCommands/src/main/webapp/index.html");
Couldn't find file - in karaf console.
i tried URI u = new URI("index.html"); to, but it didnt work.
Please help me :(
Error log
Ok I guess you only need to specify the path correctly and judging from your project structure you need:
URI u = new URI("src/main/webapp/index.html");
The path /MyCommands/src/main/webapp/index.html that gives you the error signifies an absolute path in your machine. Does this correspond to your actual folder structure?
If you wanted a relative path (beginning from your source root folder you should not use the first forward slash /, something like MyCommands/src/main/webapp/index.html but in your case I think MyCommands/ is unnecessary.
Edit:
Copying from the Class Desktop documentation for browse() method :
IOException - if the user default browser is not found, or it fails to
be launched, or the default handler application failed to be launched
Judging from the above maybe you should check if your browser has some problem launching.
Can you open anyother URI instead of the one specified for example?
I'm using Jetty 8.0. to create a simple web server (html/json/png) inside my java application.
I added an handler to use jsp pages positioned inside a package (as mentioned here: http://docs.codehaus.org/display/JETTY/Embedding+Jetty):
String WEBAPPDIR = "com/econorma/jsp/resources";
String CONTEXTPATH = "/jsp";
URL warUrl = WebApplication.class.getClassLoader().getResource(WEBAPPDIR);
final String warUrlString = warUrl.toExternalForm();
WebAppContext webapp = new WebAppContext(warUrlString, CONTEXTPATH);
I tested this code in Eclipse without any problems: html and jsp both work.
My problem come when I run my jar deployed. I get NULL POINTER exception in the getClassLoader line.
I try to put the slash at the end of WEBAPPDIR as mentioned in one StackOverflow post but, also if I solve the null pointer exception, I can't me it work.
You need to put the updated codes of jsp and html files back into the jar to work properly.
The local jsp pages in the package com.econorma.ui.resources will be available only for development process and when you export your project as a war file. The jars will not have the changes that you made in jsp pages which you had in com.econorma.ui.resources.
So you need to copy of jsp or html files from the package you created. And then put these files in the jar in the appropriate packages and update it.
Now you have to build your project again after installing the new jars files and restart your jetty server to see the changes and you should be able to run your server without errors. Hope this helps.
There was two problems for my embedded jetty and jsp:
1-Missing code before calling my webClass:
System.setProperty("org.apache.jasper.compiler.disablejsr199", "true");
2-The Eclipse export to prepare the jar: I used the EXTRACT method and non the PACKAGE one and so it wasn't possibile to find jsp inside the jar.
I've uploaded my .war file to /webapps.
I'm able to see it in the path, but if I got to //localhost:8080/vdma-vaadin-0.1-SNAPSHOT.war it's not pulling up...
Any tips to look for?
You don't want to access the WAR directly. The WAR is just the web application archive. To access the web application try this:
http://localhost:8080/vdma-vaadin-0.1-SNAPSHOT
That is assuming there are no errors preventing your application from starting
You should go to
http://localhost:8080/vdma-vaadin-0.1-SNAPSHOT
instead of
http://localhost:8080/vdma-vaadin-0.1-SNAPSHOT.war
That's it.
You should go to localhost:8080/folder_name_in_webapps_folder
Also there can be some problems about your code, you may check in tomcat/logs.