Richard Broersma

Submitted Assignment Servlets-3a (Reverse2), 2nd attempt.

You'll find that the instructor's solutions are geared to accomplish a task with the least effort for the computer processor - at least this was my take on the nitpicking that I received. So you'll find that your tightly compact elegant solutions need to have a bit more code to make life a little easier for the processor. And at other times when you have way too much code, you'll find that there is a better way of solving the problem all together.

So - in my case - the nitpicking didn't explicit state preferred practices. However, the nitpickers' nudging of my code seemed to imply that there were cases where I wasn't following "good coding" practices.

While attempting to solve the Servlets-4b assignment, I've noticing that my solution continues to become more and more convoluted and it still does not produce some of the desired results.

After reading the intent of the assignment, it seemed to me that the containers built-in authentication api or servlet filters could be well suited to solving this problem. However, the assignment deliverables did not show that these features are used as a solution. So I attempted to mimic filters by decorating/wrapping my application ActionHandler classes with a subclass containing authentication logic. My thought being, I+ didn't want to duplicate all of this code in each action handler, so instead I'd wrap the authentication logic around the application logic.

So everything work good upon until a certain point. The Authentication sub-class .doAction() is called, the object detects that there so no authentication cookie set, so it forwards the ServletData object to the videologin.jsp rather than the actionhandler designated in by the "action" in ServletData request object.

The password is then entered by the user using the webpage rendered by the videologin.jsp, the container sends to new request and response objects back to ActionServlet, which then finds the "login" action handler. The login action handler creates the cookie and adds it to the ServletData and then *forwards* the request/response objects to .... ???; Well the login action handler doesn't know who called it so it doesn't have another JSP to redirect its response to, and it doesn't know which action handler was responsible for its invocation. So at this point, I'm stuck.

However not wanting to hold up the rest of the assignment design for this little problem, I continued testing the login actionhandler by hard coding the "com.javaranch.drive.video.VideoServlet" in the forward and I set a desired "action" for testing in the ServletData object. But at this point I get errors emitted from the container once the forward() is processed.

So, does anyone have a little advice to offer on a good design practices to use for password authentication using cookies? I probably wouldn't need to ask this question if I had more experience with Servlets.

Ernest Friedman-Hill wrote:what's bad are classes that couple different layers of the app and prevent them from varying independently. If you use the same beans for persistence and UI, then if need a new field in the gui, you suddenly find yoursélf modifying database code.

This makes sense. Thank you for the clarification.

Ernest Friedman-Hill wrote:In this application, the JSP talks to the servlet via HTTP, and the servlet uses the VideoData class since they're together in the same package. The JSP has no reason to touch the VideoData class, and so it's not marked public. There's a real nice separation of concerns -- this makes it real easy to understand the code.

Does this imply that it is a recommended practice to translate all bean data into key/value pairs in a hash before passing the data to JSPs via the response object?

Several source files are provided for this assignment. One such file is VideoData.java, which has the following class definition:/VideoData.java package com.javaranch.drive.videos ; class VideoData { //... Constructors, Setters, Getters }Was it an intentional part of this assignment to *not* declare this class as public? The usefulness of this class certainly diminishes since JSPs - which are outside of the com.javaranch.drive.videos package - cannot reference this class directly.

Okay, that make sense. But now I'm confused about one aspect of the Cattle-Drive Assignment Servlets-4a. I'll open up a new thread for that question.

Since JSP files will eventually be translated to .java files which eventually will be compiled into java classes, it it possible to declare a JSP as part of a development package.


Basically, does JSP have an equivalent to the java "package" statement?

Thanks Carol.

Ed Connery wrote: Shall I go ahead with 2.0.3?

I went with it and it seems to work okay.

Ed Connery wrote:When I go to the Oracle site I only see Java EE 6, and I don't know if that's compatible with JDK 1.5.

I downloaded glassfish - which came with javaee 6. There was only one problem that I encountered that was related to moving the javaee.jar from the glassfish\lib to the java\bee\lib\production which is found in the section on deployment using ANT.

Jaikiran Pai helped me with a solution to for this problem, which is found here.

Since I was having a hard time understanding the MVC2 model behind servlets and JSP, I decided it'd be helpful to read a book on the subject.

Examples in the cattle drive demonstrate JSP with use of scriptlets. However, the book advocates that scriptlets are "bad" and EL + JSTL are "good."

What is the preferred practice to use in the cattle drive?

Carol, on the old assignment log (that was replaced with this log), there was a link to a page that explained the meaning of the colors of the assignment list. If possible, would you be able to add that link back to the assignment list?

PostgreSQL should put large text fields in a Toast table automatically for your.

Thanks! That fix it:

C:\bee\lib\development>xcopy /E c:\glassfish3\glassfish\modules .\modules\ C:\glassfish3\glassfish\modules\acc-config.jar ... 253 File(s) copied C:\bee\lib\development>cd ..\.. C:\bee>javac -g -d .\build\classes -cp "C:\bee\lib\development\lib\javaee.jar;C:\bee\lib\production\jr.jar;C:\bee\build\classes" -sourcepath "C:\bee\src\java src\java\com\javaranch\drive\BeeServlet.java C:\bee>

Now regarding the instruction in the Cattle Drive (i.e. Tree struction and files to be copied), should these instructions be amended considering the makeup of modern versions of glassfish?

I copied the bee folder upto the root directory. Now there are no spaces in the classpath. It looks like I'm still getting the same error.

The following is the result when I try to compile with javaee.jar in my lib directory versus having javaee.jar in the glashfish\lib directory:

C:\bee>copy c:\glassfish3\glassfish\lib\javaee.jar c:\bee\lib\javaee.jar Overwrite c:\bee\lib\javaee.jar? (Yes/No/All): yes 1 file(s) copied. C:\bee>javac -g -d .\build\classes -cp "C:\bee\lib\javaee.jar;C:\bee\lib\production\jr.jar;C:\bee\build\classes" -sourcepath "C:\bee\src\java" src\java\com\javaranch\drive\BeeServlet.java src\java\com\javaranch\drive\BeeServlet.java:4: package javax.servlet.http does not exist import javax.servlet.http.*; ^ src\java\com\javaranch\drive\BeeServlet.java:6: cannot find symbol symbol: class HttpServlet public class BeeServlet extends HttpServlet ^ src\java\com\javaranch\drive\BeeServlet.java:8: cannot find symbol symbol : class HttpServletRequest location: class com.javaranch.drive.BeeServlet public void doGet( HttpServletRequest request, HttpServletResponse response ) ^ src\java\com\javaranch\drive\BeeServlet.java:8: cannot find symbol symbol : class HttpServletResponse location: class com.javaranch.drive.BeeServlet public void doGet( HttpServletRequest request, HttpServletResponse response ) ^ 4 errors C:\bee>javac -g -d .\build\classes -cp "C:\glassfish3\glassfish\lib\javaee.jar;C:\bee\lib\production\jr.jar;C:\bee\build\classes" -sourcepath "C:\bee\src\java" src\java\com\javaranch\drive\BeeServlet.java C:\bee>