It's not what your program can do, it's what your users do with the program.
It's not what your program can do, it's what your users do with the program.
Bear Bibeault wrote:Because there is no context path in your URL, I assume that you have this deployed as the ROOT web app? If not, then the problem is just that you are omitting the context path from the URL.
It's not what your program can do, it's what your users do with the program.
It's not what your program can do, it's what your users do with the program.
Joe Areeda wrote:I am confused about the difference between context path and server path
It's not what your program can do, it's what your users do with the program.
Joe Areeda wrote:A context element is the name of the web application which is usually the name of the .war file.
A context path starts with a slash and may have a directory structure but ends with the name of the war file deployed.
In this discussion a servlet is a class defined in war file (context element) that is derived from HttpServlet and overrides doGet and/or doPost so that it is able to respond to a client (browser) request.
For clarity the war file and the servlet class should be named differently
unlike a .jar application where they are named the same (at least by convention in NetBeans 7).
The servlet path is specified in web.xml whereas the context is set when the app is deployed.
To make a servlet the default application for a virtual host (that is what responds to https://example.com/) the web server
I guess part of the problem is I use a full feature IDE like NetBeans
It's not what your program can do, it's what your users do with the program.
It's not what your program can do, it's what your users do with the program.
Bear Bibeault wrote:I cannot agree as your original implementation employs Java scriptlets in a JSP which have been obsolete for over 12 years.
It's not what your program can do, it's what your users do with the program.