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
You probably already know that PrimeFaces is using jQuery under the covers. PrimeFaces Selectors are based on jQuery. Anything which you specify in @(...)
will be used as jQuery selector on the current HTML DOM tree. For any found HTML element, which has an ID, exactly this ID will ultimately be used in the update
.
Basically, for a update="@(.myclass)"
, PrimeFaces will under the covers roughly do this:
var $elements = $(".myclass");
var clientIds = [];
$.each($elements, function(index, element) {
if (element.id) {
clientIds.push(":" + element.id);
}
});
var newUpdate = clientIds.join(" "); // This will be used as `update` instead.
So, in case of e.g.
<h:form id="formId">
<h:outputText id="output1" styleClass="myclass" ... />
<h:outputText styleClass="myclass" ... />
<h:outputText id="output3" styleClass="myclass" ... />
</h:form>
this command button update
<p:commandButton ... update="@(.myclass)" />
will end up with exactly the same effect as
<p:commandButton ... update=":formId:output1 :formId:output3" />
Note that this also works for autogenerated IDs. I.e. the <h:form id>
is not mandatory.
Sometimes I have a problems with PFS. Is there something what you are should keep in mind if you are using PFS ?
It can happen that you selected "too much" (e.g. @(form)
doesn't select current form, but all forms, exactly like $("form")
in jQuery!), or that you actually selected nothing (when the desired HTML DOM element has actually no ID). Investigating element IDs in the HTML DOM tree and the request payload in the HTTP traffic monitor the should give clues.
The desired elements in the HTML DOM tree must have an (autogenerated) ID. The javax.faces.partial.render
request parameter in the HTTP traffic monitor must contain the right client IDs. The element's rendered
attribute in the JSF component tree must evaluate true
during update. Etcetera.
In your particular example, the <h:outputText>
won't end up in the generated HTML output with any ID. Assigning it an id
should solve your problem with updating it.
So, this example won't work
<h:form>
<h:outputText value="#{bean.text1}" styleClass="myClass" />
<p:commandButton value="Update" update="@(.myClass)" />
</h:form>
but this example will work (note that assigning the form an ID is not necessary):
<h:form>
<h:outputText id="myText" value="#{bean.text1}" styleClass="myClass" />
<p:commandButton value="Update" update="@(.myClass)" />
</h:form>
Best Answer
There is nothing out of box that will give you what you describe because these are all situations that occur on different layers.
This is typically because an unhandled exception made its way up the call stack. If you improve your code for exception handling then these circumstances should be caught and logged.
Improved exception handling and logging at all application layers will help capture all errors and exceptions in a single log file on the application server.
Firebug catches network errors in asynchronous postbacks as well as Javascript exceptions. This is completely a client side concern as the server just derives the markup. It might be possible to catch all Javascript exceptions before they are propagated up to Firebug and to send an asynchronous error report to the server for the server to log. This shouldn't be too terribly difficult to implement.
Again, better logging in your validator methods will be able to put this information in the application server logs so that you have all of this information in one place.
The bottom line is that these are all situations where they become a non-issue for developers who learn how to intuitively include good Instrumentation code throughout their applications.