No, the structure you found is how Java handles it (that is, with overloading instead of default parameters).
For constructors, See Effective Java: Programming Language Guide's Item 1 tip (Consider static factory methods instead of constructors) if the overloading is getting complicated. For other methods, renaming some cases or using a parameter object can help. This is when you have enough complexity that differentiating is difficult. A definite case is where you have to differentiate using the order of parameters, not just number and type.
JSP is a Java view technology running on the server machine which allows you to write template text in client side languages (like HTML, CSS, JavaScript, ect.). JSP supports taglibs, which are backed by pieces of Java code that let you control the page flow or output dynamically. A well-known taglib is JSTL. JSP also supports Expression Language, which can be used to access backend data (via attributes available in the page, request, session and application scopes), mostly in combination with taglibs.
When a JSP is requested for the first time or when the web app starts up, the servlet container will compile it into a class extending HttpServlet
and use it during the web app's lifetime. You can find the generated source code in the server's work directory. In for example Tomcat, it's the /work
directory. On a JSP request, the servlet container will execute the compiled JSP class and send the generated output (usually just HTML/CSS/JS) through the web server over a network to the client side, which in turn displays it in the web browser.
Servlet is a Java application programming interface (API) running on the server machine, which intercepts requests made by the client and generates/sends a response. A well-known example is the HttpServlet
which provides methods to hook on HTTP requests using the popular HTTP methods such as GET
and POST
. You can configure HttpServlet
s to listen to a certain HTTP URL pattern, which is configurable in web.xml
, or more recently with Java EE 6, with @WebServlet
annotation.
When a Servlet is first requested or during web app startup, the servlet container will create an instance of it and keep it in memory during the web app's lifetime. The same instance will be reused for every incoming request whose URL matches the servlet's URL pattern. You can access the request data by HttpServletRequest
and handle the response by HttpServletResponse
. Both objects are available as method arguments inside any of the overridden methods of HttpServlet
, such as doGet()
and doPost()
.
JSF is a component based MVC framework which is built on top of the Servlet API and provides components via taglibs which can be used in JSP or any other Java based view technology such as Facelets. Facelets is much more suited to JSF than JSP. It namely provides great templating capabilities such as composite components, while JSP basically only offers the <jsp:include>
for templating in JSF, so that you're forced to create custom components with raw Java code (which is a bit opaque and a lot of tedious work) when you want to replace a repeated group of components with a single component. Since JSF 2.0, JSP has been deprecated as view technology in favor of Facelets.
Note: JSP itself is NOT deprecated, just the combination of JSF with JSP is deprecated.
Note: JSP has great templating abilities by means of Taglibs, especially the (Tag File) variant. JSP templating in combination with JSF is what is lacking.
As being a MVC (Model-View-Controller) framework, JSF provides the FacesServlet
as the sole request-response Controller. It takes all the standard and tedious HTTP request/response work from your hands, such as gathering user input, validating/converting them, putting them in model objects, invoking actions and rendering the response. This way you end up with basically a JSP or Facelets (XHTML) page for View and a JavaBean class as Model. The JSF components are used to bind the view with the model (such as your ASP.NET web control does) and the FacesServlet
uses the JSF component tree to do all the work.
Related questions
Best Answer
The
DefaultServlet
is designed to look at the request URI after thecontextPath
.In your example code when you changed the url-pattern of your servlet from
/
to/foo/*
the resulting file being looked for on disk is now includes the/foo/
portion.In other words, a request URI of
/css/main.css
results in the file (on disk) it expects to find as./src/webapp/foo/css/main.css
Your example has a few flaws. It's not a wise have an empty resource base for your
ServletContextHandler
, as theServletContext
itself needs access to that configuration value.You would fix that by removing ...
and using ServletContextHandler.setBaseResource(Resource) instead ...
This will allow the following
ServletContext
methods (used by countless servlet libraries) to work as wellString getRealPath(String path)
URL getResource(String path)
InputStream getResourceAsStream(String path)
Set<String> getResources(String path)
Finally, to make this setup sane in the
ServletContextHandler
, you'll add thedefault
Servlet name, on the "default url-pattern", which happens to be implemented as theDefaultServlet
.Like this:
Now, if you also have a need to serve static content from request URI
/foo/*
out of a directory not belonging to the webapp, you can do that too. That will require you to setup anotherDefaultServlet
that does not participate in theServletContext
.An example of this setup is ...
This uses a second
DefaultServlet
, using a unique resource base for thatDefaultServlet
only, and mapped to a url-pattern that ends in/*
.Finally, the init-parameter for this second
DefaultServlet
is told to use the pathInfo of the Request URI and not split on the contextPath like it normally does.This stand alone
DefaultServlet
declaration does not participate in theServletContext
and libraries will not be able to see or access the content from thatDefaultServlet
via theServletContext
methods. However all incoming HTTP client requests can request the content easily via that url-pattern.