Bob Kerfoot

Ranch Hand
+ Follow
since Oct 01, 2000
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Bob Kerfoot

I took the test yesterday and the actual exam is much easier than any of the mocks. The one caveat to be aware of during the actual exam is that you cannot review the drag and drop questions without resetting the answers back to their initial unanswered state. I saw this warning in another post and it helped me during the exam so I'm passing it along as well.
My preparation:
- EJB course at DePaul.
- Read parts of Enterprise JavaBeans, 3rd edition.
- Read all of Head First EJB.
- Read parts of EJB specs.
- Took all EJBPlus mock exams.
- Took two softSCBCD exams.
I thought the Head First book did an excellent job of explaining EJB 2.0 at a macro level and the specs and Enterprise JavaBeans book are useful for fleshing things out at a more fine grained level.
I thought the EJBPlus mock exams were the closest to the real exam and I definitely learned a few things about EJB while using them.
Bob Kerfoot, MS
SCJP 1.2, SCWCD, SCBCD
20 years ago
Mike,
You can use the <error-page> element under <web-app> to declaratively define error pages that respond to specific error codes or exception classes. I have included the following explanation from the Java� Servlet Specification Version 2.3:


SRV.9.9.2 Error Pages
To allow developers to customize the appearance of content returned to a wweb client when a servlet generates an error, the deployment descriptor defines a list of error page descriptions. The syntax allows the configuration of resources to be returned by the container either when a servlet sets a status code to indicate an error on the reponse, or if the servlet generates an exception or error that propogates to the container.
If a status code indicating an error is set on the response, the container
consults the list of error page declarations for the web application that use the status-code syntax and attempts a match. If there is a match, the container returns the resource as indicated by the location entry.
A servlet may throw the following exceptions during processing of a request:
Welcome Files
� runtime exceptions or errors
� ServletExceptions or subclasses thereof
� IOExceptions or subclasses thereof
The web application may have declared error pages using the exception-type element. In this case the container matches the exception type by comparing the exception thrown with the list of error-page definitions that use the exceptiontype element. A match results in the container returning the resource indicated in the location entry. The closest match in the class heirarchy wins.
If no error-page declaration containing an exception-type fits using the class-heirarchy match, and the exception thrown is a ServletException or subclass thereof, the container extracts the wrapped exception, as defined by the ServletException.getRootCause method. A second pass is made over the error page declarations, again attempting the match against the error page declarations, but using the wrapped exception instead.
Error-page declarations using the exception-type element in the deployment descriptor must be unique up to the class name of the exception-type. Similarly, error-page declarations using the status-code element must be unique in the deployment descriptor up to the status code.
The error page mechanism described does not intervene when errors occur in servlets invoked using the RequestDispatcher. In this way, a servlet using the RequestDispatcher to call another servlet has the opportunity to handle errors generated in the servlet it calls.
If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure the status code of the response is set to status code 500.


The <error-page> element definition from the deployement despcritor's DTD follows:

An example usage of <error-page> from the Java� Servlet Specification
Version 2.3 follows:

Bob Kerfoot
20 years ago
Pourang,
Both roles will evaluate to true in
request.isUserInRole("role-link-role");
request.isUserInRole("role-name-role");
Basically, the role specified in the <role-name> element is defining an alias for the actual role specified in the <role-link> element and its associated <security-role> element. As such, your servlet recognizes the authenticated user as being in both the actual role from <role-link> and the alias role in <role-name>. This is useful because if you deploy the servlet classes without the source code and explicitly hard-code a role name in the servlet source, the <security-role-ref> element allows you to map this internal hard-coded role as an alias to an actual role defined with a <security-role> element.
e.g.
With web.xml as:
<web-app>
<servlet>
<servlet-name>myServlet</servlet-name>
<servlet-class>MyServlet</servlet-class>
<security-role-ref>
<role-name>aliasRole</role-name>
<role-link>actualRole</role-link>
</security-role-ref>
</servlet>
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>/myServlet</url-pattern>
</servlet-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>myServlet Setup</web-resource-name>
<url-pattern>/myServlet</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>actualRole</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>actualRole</role-name>
</security-role>
</web-app>
MyServlet will evaluate both of the following to true:
request.isUserInRole("aliasRole");
request.isUserInRole("actualRole");
However, if you are deploying without the source, the deployment team(s) in the field may not use the same actual role names in their environment(s) as you have hard-coded so you should just document the hard-coded role name used in the servlet and not worry about using the actual role in the servlet source even though your servlet will recognize either as valid for an authenticated user.
Bob Kerfoot

[ August 08, 2003: Message edited by: Bob Kerfoot ]
20 years ago
Pourang,
Both roles will evaluate to true in
request.isUserInRole("role-link-role");
request.isUserInRole("role-name-role");
Basically, the role specified in the <role-name> element is defining an alias for the actual role specified in the <role-link> element and its associated <security-role> element. As such, your servlet recognizes the authenticated user as being in both the actual role from <role-link> and the alias role in <role-name>. This is useful because if you deploy the servlet classes without the source code and explicitly hard-code a role name in the servlet source, the <security-role-ref> element allows you to map this internal hard-coded role as an alias to an actual role defined with a <security-role> element.
e.g.
With web.xml as:
<web-app>
<servlet>
<servlet-name>myServlet</servlet-name>
<servlet-class>MyServlet</servlet-class>
<security-role-ref>
<role-name>aliasRole</role-name>
<role-link>actualRole</role-link>
</security-role-ref>
</servlet>
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>/myServlet</url-pattern>
</servlet-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>myServlet Setup</web-resource-name>
<url-pattern>/myServlet</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>actualRole</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>actualRole</role-name>
</security-role>
</web-app>
MyServlet will evaluate both of the following to true:
request.isUserInRole("aliasRole");
request.isUserInRole("actualRole");
However, if you are deploying without the source, the deployment team(s) in the field may not use the same actual role names in their environment(s) as you have hard-coded so you should just document the hard-coded role name used in the servlet and not worry about using the actual role in the servlet source even though your servlet will recognize either as valid for an authenticated user.
Bob Kerfoot
20 years ago
sharon,
You can use the HttpServletRequestWrapper and HttpServletResponseWrapper classes with RequestDispatcher.include(request,response).
Per the Javadocs for RequestDispatcher.include:
"The request and response parameters must be either the same objects as were passed to the calling servlet's service method or be subclasses of the ServletRequestWrapper or ServletResponseWrapper classes that wrap them. "
Let me know if you need more details.
Bob Kerfoot
bkerfoot@wideopenwest.com
20 years ago
ogeh,
I support most of it. However, as regards Construct 3, if you look at page 77 of the JSP 1.2 specification it states that the default value for the flush attribute is false:
"The flush attribute controls flushing. If true, then, if the page output is buffered and the flush attribute is given a �true� value, then the buffer is flushed prior to the inclusion, otherwise the buffer is not flushed. The default value for the flush attribute is �false�"
As regards Construct 1, neither the Servlet 2.3 specification nor Javadocs specify that an automatic flush of the response output stream occurs before the content of the other component is included. I found through testing that Tomcat 4.1.24 indeed does not flush the buffer and send the status code and headers to the client. Specifically, after an rd.include() you can still do response.sendError(404, "Some error") without raising an exception. However, if you execute response.flushBuffer() then response.sendError(404, "Some error"), a java.lang.IllegalStateException will be raised.
Therefore, unless there is a hidden flush mechanism that does not commit the response, I still contend that the buffer is not flushed before the rd.include() and the empirical evidence as stated above seems to bear this out.
Let me know what you think.
Bob Kerfoot
20 years ago
Ogeh,
You can still send HTTP headers from the including servlet after using a RequestDispatcher to include() the content of another component as long as the response has not been committed. A response has been committed if it has already had its status code and headers written. You can check the commit status with response.isCommitted().
Also, neither the Servlet specification nor Javadocs specify that an automatic flush of the response output stream occurs before the content of the other component is included.
Bob Kerfoot
20 years ago
Awesome!!!
Bob Kerfoot
20 years ago
The RequestDispatcher's forward method and the jsp:forward action are both server-centric. Specifically, your request is forwarded to the target resource on the server without notifying the client first. Thus, a single request requires only a single round trip between client and server.
In contrast, the sendRedirect method sends a message back to the client instructing it to request the target resource. Thus, a single request requires two round trips between the client and server to get the final target resource.
Bob Kerfoot
20 years ago
JSP
Eric,
Thanks for the congrats. I am going to finish my MS in CS in November. So far I have a solid GPA and am in the Upsilon Pi Epsilon honor society in addition to the two Java certifications. I have taken OO Compiler Design, Advanced/Optimizing OO Compiler Design, as well as various theoretical topics such as Design and Analysis of Algorithms. I have also taken Patterns based OO Analysis and Design and the J2EE(servlet/JSP) courses. I am taking Document Interchange/XML programming now and will be taking the Concurrent Programming, Distributed Programming, and J2EE(EJB, JNDI and JMS) courses in the fall.
Hopefully, I will be able to find a challenging job when I complete the degree.
Good to see another other CTI guy in here!
Bob Kerfoot
Go Demons!!!
20 years ago
Tim is correct in that
getServletContext().getRealPath(java.lang.String path)
will return null if the webapp is deployed in a WAR file.
However, as always, specific knowledge of the deployment environment is required whether you hard code the absolute path in the deployment descriptor and/or the program or use getServletContext().getRealPath("/resource");
Specifically, if you change your directory structure or redeploy the webapp to a new machine with different drive letters then your file processing can break as well.
Therefore, as always, there is no magic bullet. Specific knowledge of and testing for your actual deployment environment equals quality production deployments.
Bob Kerfoot
20 years ago
Glad I could help.
Bob Kerfoot
20 years ago
Kate,
I think it may be a problem with your path resolution. I ran your code on my machine with a bad path "/orderNumData" and was also unable to create the new file. However, after using
String fileName = getServletContext().getRealPath("/orderNumData");
all worked as expected and I created the new file "orderNumData" in my application context root directory.
$CATALINA_HOME/webapps/applicationContextRoot/orderNumData
You can adjust your file location below the context root by adding directory info as needed. For example,
String fileName = getServletContext().getRealPath("/myDir/orderNumData");
will create the new file as
$CATALINA_HOME/webapps/yourApplicationContextRoot/myDir/orderNumData
Let me know if this takes care of the problem.
Bob Kerfoot
20 years ago
Tomcat 4.1.24
Bob Kerfoot
SCJP 1.2
SCWCD
20 years ago