Bryan Basham

Hello,

While I know nothing about "Jwebplus", I suspect that you will be fine with the v4 mock because the SCWCD v4 exam objectives are identical with the SCWCD v5 exam.

Good luck,
Bryan

Congratulations, Joy!

That's a great score. Good luck with the SCEA exam.

Cheers,
Bryan

Hi Paulo,

Typically, form-based authentication (login) is combined with HTTPS. So even though the password is sent "in the clear" in the request parameters, the whole HTTP request is encrypted between the client and server; therefore, the password cannot be read by a third-party in transit.

So, yes by itself form-based auth is insecure, but when combined with HTTPS it is very secure. And yes, many other web frameworks would also suffer from this issue not just JavaEE.

HTH,
Bryan

Imagine you have an HTTP request for "/MyServlet". The web container will create a processing chain like this request->MyFilter->MyServlet.

Now imagine a different HTTP request for "/index.jsp". In this case, the MyServlet servlet is not applicable to the request and therefore the MyFilter filter is also not applicable.

Given these servlet and filter mappings, "/MyServlet" is the only HTTP request URL that will be handled by the filter and this is because "/MyServlet" is the only URL pattern that matches the MyServlet servlet.

Make sense?

Cheers,
Bryan

James' answers are totally accurate. The author of that question appears to be confusing DAO with the TO pattern.

What no one has said yet is: What really is the TO pattern about. James mentions that TO is used for "transferring data from one object-based layer to another." This is correct but there is a deeper purpose. The primary purpose of TO is reduce network traffic between a remote business tier and the web tier.

If a remote business tier exposed an Entity EJB to the web tier, then every access method (getFirstName, getLastName, getAge, getGender, etc) would invoke a remote call to the business tier. The TO pattern reduces this traffic to one method call: getCustomerData():CustomerTO. This method, which is usually part of a remote Session bean (a'la Session Facade pattern), collects all of the customer data from the Customer Entity bean and packages it up into a Serializable object which is passed across the network in one transfer. Yes, this will be a bigger packet of data being transferred across the network, but the greater performance cost is the accumulative round-trip time of the multiple accessor calls describe above.

Hope that helps.

Note that the TO pattern is not needed if the web and business logical tiers are on the same physical machine (same JVM). In this situation, there is no network traffic when the web tier calls the individual accessor methods.

Regards,
Bryan

Amit, is absolutely correct.

By default, every JSP is given an implicit HttpSession object. This is in stark contrast with the servlet model in which the developer must actively create the session object. This is one of the things I don't like about the JSP specification.

If you do not want a JSP to include a session object, then you must include the following page directive:
<%@ page session="false" %>

Now, if you add this directive to Thilakk's original JSP code, then a NullPointerException will be thrown because the request.getSession(false) result will be null and calling the getAttribute method on a null object throws an NPE.

Make sense?

Cheers,
Bryan

WOW!!

I am so impressed with you all. I have been part of the Internet since 1984 when I worked for NASA; in the days when "community" meant email distribution lists and usenet. I can honestly say that JavaRanch has the best community I have ever seen. It is easy to express opinions and answer questions, but what I am most impressed with is the huge numbers of people willing to ask questions. Having been an instructor for Sun, I know how much courage it takes to ask questions. On the other side, I am also impressed with the folks that answer questions in the spirit of what we call in HeadFirst "no dumb questions". I almost never seen "flame wars" on JavaRanch which was all too common in the early days of the Internet.

You all deserve a giant, Internet, group hug. Consider yourself hugged!

Oh yeah, and thanks specifically to Chintu for the great bday poem; that warmed my heart.

Cheers,
Bryan

Thank you, Bert, and everyone. I gave myself a special birthday gift this year: I have quit corporate life and I am now beginning life as a consultant. Thanks again for all of the "well wishes". Cheers, Bryan

This is an interesting question and I suspect that your intuition is correct. The best way to find out is to just try it in Tomcat (or your favorite web container).

I can tell you that you won't see this scenario in the SCWCD exam.

Cheers,
Bryan

Hi Tony,

Unfortunately, I won't be much help answering your question because I honestly don't know what the flush attribute does. But I can tell you that it will not appear on the SCWCD exam. If you really need to know about this (for a project), then I would recommend reading about it in the JSP spec.

Cheers,
Bryan

I agree with both Deepti and Michael.

The HFSJ chapters on custom tags is about as good as I have seen (or created; I was a course developer for Sun in a previous life).

But nothing compares with learning from experience. I would recommend coding a simple loop custom tag from scratch. For example, have you ever needed to loop over the values of an enumerated type? (to populate the <option>s of a <select> tag for example?)

Imagine your webapp includes an enum of hobbies:
package com.example; public enum Hobby { READING, JOGGING, SKIING, KNITTING, DUCK_CALLS }

And you want a JSP form to ask the user select their hobbies. You could do this using scriptlet code like this:
<select name='hobby' multiple='true'> <% for ( Hobby h : Hobby.values() ) { %> <option value='<%= h %>'> <%= h %> </option> <% } %> </select>

Buut as we know "scriptlets are bad, ngKay" (a'la Mr. Garison from South Park).

So a better solution is to use a custom tag:
<select name='hobby'> <myTags:forEnum var='h' enum='com.example.Hobby'> <option value='${h}'> ${h} </option> </myTags:forEnum> </select>

Your mission --if you choose to accept it-- is to develop the forEnum tag. The easiest solution will be to develop a "Simple Tag" handler. Start there, but when you get that done create a second implementation using a "Classic Tag" handler. When you get that created you will know 80% of what you will need for the SCWCD exam. Note: a "Tag File" is not an appropriate technology for this exercise.

Good luck on your mission and if you need assistance feel free to email me at b_basham@yahoo.com

Regards,
Bryan

Great job, Kathiresan!

Darn, I really did try to make the SCWCD 1.5 harder than the SCWCD 1.4, but I guess I failed.

Well anyway... CONGRATULATIONS!!!

Warm regards,
Bryan

Hi Tony,

It depends upon how much content servlet pushed to the response writer (or output stream). The web container will buffer some content and throw that content away if the servlet forwards to a ReqDisp or does a redirect.

However, if the servlet pushed more content than the buffer can hold, then the web container is required to commit that buffer (and the response header) to the browser. After that has happened, any attempt to forward or redirect will fail.

Regards,
Bryan
[ July 24, 2008: Message edited by: Bryan Basham ]

Originally posted by Amit Prakash Singh:
what about the fact that . dot operator can not be used with the list and array. In both D & F, . is being used for accessing something from the list.

Actually, in option D the dot operator is being used on a Map.

In option F, the dot operator is being used on a List; and as Craig mentioned, this is why option F is one of the correct answers ("it will cause an error").

Make sense?

Cheers,
Bryan

If you are using Java5, then the answer is 'yes' because Java will automatically converted your primitive value into a wrapper object before storing it into the session attribute map. This Java5 feature is called autoboxing. So this code works fine:
int x = 47; request.setAttribute("x", x); .... x = (Integer) request.getAttribute("x"); // I think the cast is necessary, but maybe not... try it!

HTH,
Bryan