Alexandre Cervieri

Hello Krishna,
I know nothing about SCDJWS, not even the summary. However, I'm studying for SCWCD and its objectives don't say anything about web services. It is focused on: servlets, filters, JSP, EL, custom/simple tags, and some design patterns.
Some of the concepts that are included in SCWCD may be also important for web services, but WS are completly out of the SCWCD scope.
I believe that if you are aiming to master in web services development you should prepare for SCDJWS, and it must be some "head first SCDJWS" book out there.
Regards.

Hi Will,

What you are seeing as a result of your code is correct. You will not have the result you want with you current JSP. Let me explain: You have a single JSP with the following code, right?

<form action="getEmployee">
Name: <input type="text" name="name"><br>
<input type="submit">
</form>

<jsp:useBean id="employee" class="test.Employee" scope="session">
<jsp:setProperty name="employee" property="*" />
</jsp:useBean>

When the user calls this single JSP what happens is: a html form with a input text will be shown in the browser, in the server a bean called employee will be created if it doesn't exists in the session; only if the bean is being created all its properties will be set according to the current request parameters.

Then, when in the browser you click the submit button you will be calling the servlet directly and not the JSP, so, since the JSP will be called once your parameters (only the 'name' parameter in fact) will never be set in the bean.

To achieve the result you want you should remove the jsp:setProperty from the body of the jsp:useBean and submit the html form to the same JSP before going to the servlet.

I hope this help. I'm sure that there are better ways to do that besides the one I exemplified to you.

Regards.

Hi Alec, where did this question come from?
I don't understand how A and B could be right. Every book or web page I read about writing binary data from a servlet they emphasize that we should use the getOutputStream() and this should also be the answer for certification questions. Are you sure the answers are right? I mean, I was pretty sure about that, now I think that I know nothing about servlets

Hi, please correct me if I'm wrong. If you are handling different exception-types you can have multiple error-pages in a single DD, but you cannot have two error pages specifing the IOException for example, right?

Originally posted by B Sathish:
D is the right answer

Hi Alec, maybe I'm losing some detail, but why did you consider this question difficult?
I agree with Sathish the answer is D and it seems to be an easy question.
[ September 28, 2005: Message edited by: Alexandre Cervieri ]

Originally posted by Gouri Bargi:
An interesting question ...

suppose we are creating a database connection in the init method and releasing it in destroy - what will happen if we ourselves call destroy in the doGet()? I do not think the container will know we called this method, and call init method again. It will believe that the servlet is fit for service. Any idea?

- Gouri

This is the best example to explain why you cannot call the life-cycle methods yourself. They are meant to be called by the container, and it doesn't have a way to find out whether someone else already called the destroy method, for example, or not. So, calling the destroy method in the service method in the situation you described will certainly generate a problem when your servlet will be invoked again.

Hello,
I didn't get to the tag library chapter yet but I think that you have to define http://java.sun.com/jsp/jstl/core in your deployment descriptor (web.xml) to point to the correct core tags JAR file. This JAR file should also be placed under the WEB-INF/lib directory I think.
Regards,
Alexandre.

Hello all,

Puting it all togheter, let me see if I understood this question:

* <jsp:useBean id="mystring" class="java.lang.String" />
Container will search for a "mystring" bean in the page context. If no bean with this name is found then it will create one.

* <jsp:setProperty name="mystring" property="*" />
Container will try to set all attributes that contains standard setters (setXXX) with the given property=value pairs available in the request. Since that the pair mystring=hello is in the request, the container will try to call the method mystring.setMystring(String), however this method dos not exists in the "mystring" object, then nothing happens.

* <%=mystring%>
Since the string value was not updated by the previous line, it will simple print an empty string ("").

Right?

Originally posted by Aruneesh Salhotra:
Also there is no getHeaders() method, but getHeader().

There is a getHeaders(String) method in the javax.servlet.http.HttpServletRequest interface. It returns a Enumeration of String containing all the values associated with the specified header.

Since response.sendRedirect goes to the client before reach the final destination, forwarding without this additional communication overhead with the client may be better in most of cases. Don't you think?

Good point Jim, I'm enjoying the comic style of the Head First book, all those images, graphics make me fix easily the information in my brain. However, someone may not like this style.
In fact, I'm using both books to complement each other. After reading the first pages of Head First I understood why most of people of JavaRanch like the book, Kathy Sierra was one of the creators of this site. But she's good anyway.

Hi, take a look at this thread.
Anyway, the best book is Head First Servlets & JSP (Paperback) by Kathy Sierra and others (she is great). In addition, I'm reading also the book SCWCD Exam Study Kit Second Edition : Java Web Component Developer Certification (Paperback) that is just so so. Good luck.

Hi, I've heard about HTTPUnit but I've never used it. It is supposed to be a kind of JUnit for HTTP, I don't know if it is really useful.

Originally posted by Jingh Yin:
That's what I use: http://localhost:8080. It used to be working, all the way until last Friday.

Hello Jingh,
If you really have both IIS and Apache/Tomcat listening on port 8080, this is not a good practice, because the server that start up first will get the port and the other will get an exception from the operating system (something like port already used).
If you need to have both servers, I would suggest you to change IIS to listen on port 8088, or something like that. Just configure different ports, start up both servers and try them. It should work.
Regards,
Alexandre.

Hello, I was looking at Amazon, and one of the writers of
Head First Servlets & JSP (Paperback) is Kathy Sierra. She's absolutly perfect, a very good writing style, it does not get you bored. I'm going to order this book too.
Good technical books in Brazil are some expensive! I should have bought this one!