Francois Roland

Congratulations Rohit !

I have used almost the same materials as yours and did almost the same score just one day later ;-) .

Just a piece of advice:

Learn every new features in detail. Almost half of the exam is based on subjects that were not there with the former specification.

Let me say thanks to all of you who have answered my few questions and mainly the ones who has asked them. Answering questions in the forum is to me on af the valuable things to do to prepare your exam.

Thanks to all of you.
[ March 01, 2005: Message edited by: Francois Roland ]

The answer on j2eecertificate.com is true.

With BASIC authentication, you trigger some special code in the client browser. This code encodes the username and password information in Base64, not for encryption purpose (that would be foolish) but to ensure that the data are transmitted as-is on a non-binary link (the HTTP connection). This mechanism avoids character encoding issues.

With FORM-BASE authentication, you (the application developer) are the only one that has a chance to mess with the form parameters (using javascript, vbscript, etc.). To the client browser, the custom authentication form just looks like any other applicative form. And a form is not base64-encoded by default by the common web browsers.

Remember that the only thing that makes the difference between a simple form and an authentication (apart form the deployment descriptor declaration) is the action attribute of your html form tag. So the authentication form is processed by the web browser as any other form of your application.

Great job !

Thank you.

I think there is one thing to correct:

Brief Roadmap:

19) The HttpSession - related listeners.

I'm pretty sure that there is another listener that doesn't have to be registered in the deployment descriptor: HttpSessionActivationListener.

Try this URL:
http://apache.scarlet.be/jakarta/tomcat-5/

Jose, you are right: the getProperty indeed uses the findAttribute method. This seems to be a bug of the specification that will effectively prevent someone to get a "larger" scope attribute if a "narrower" one exists.

And there is another thing odd in the code about this tag: it uses the bean type of the bean declared with the useBean tag.

Here is an example:

Imagine you store a bean of a class foo.Person with a "firstName" property under session scope with name "foo". You then store a foo.Address bean with only a "city" property under request scope with name "foo".

Now, create a JSP with the following code:
<jsp:useBean id="foo" scope="request" class="foo.Person"/> <jsp:getProperty name="foo" property="firstName"/>

If you try to execute it, you'll get really weird things...
(a ClassCastException !!!)

The only way I could get the info I wanted was using EL:
${sessionScope.foo.firstName}

There is a slight semantic difference between the event value given for the method attributeAdded(...) and the methods attributeReplaced(...) and attributeRemoved(...).

On the attributeAdded() event, the attribute name doesn't exist yet in the request scope. So the only value that the event can carry is the new one.

On the attributeRemoved() event, the only value that you can get is the value of the request attribute before it was removed.

On the attributeReplaced() event, you can get the new value by doing request.getAttribute( <attribute_name> ) . So if you wanted to know the old value, the only way to get it is through the event that get passed to the method.

This is why event.getValue() returns the "new" value when passed to the attributeCreated() method and the "old" value when passed to the attributeReplaced() or attributeRemoved() methods.

I hope my explanations will be clear enough.

[ February 27, 2005: Message edited by: Francois Roland ]
[ February 27, 2005: Message edited by: Francois Roland ]

Apparently, the preceding answers seem wrong. Here is what says the JSP 2.0 specification:

The jsp:useBean action is quite flexible; its exact semantics depends on the attributes given. The basic semantic tries to find an existing object using id and scope. If the object is not found it will attempt to create the object using the other attributes.

And in the Tomcat 5.0.30 source code (org/apache/jasper/compiler/Generator.java), I found that Tomcat uses the JspContext.getAttribute(String name, int scope) and not the JspContext.findAttribute(String name). And if the scope attribute is not given by the developper, the "page" scope is used by default.

So the scope tag attribute is well used when retrieving the bean.

Rohit, maybe you should check an error somewhere else:
- Check if the name attribute of foo.mybean is not declared as static
- Check that you have no typo in your real code (the one you pasted in your question is right)
- Check that your server isn't using another version of your code (bad web-app location, outdated cache, ...)

Apart from this, I cannot imagine what has gone wrong.

I hope these informations will help you.

As I've got this problem at work the last week, I think that a process in the waiting state or using ISM could prevent a process to being killed this way.

But I don't have the exact answer... I'm really looking forward hearing yours.

I'm not sure to understand fully.

Do you mean that even if you specify the scope attribute, jsp:usebean will search all scopes and that the scope attribute is only used when creating a new bean because an old one was not found ?

JQPlus is right.

The two interfaces HttpSessionActivationListener and HttpSessionBindingListener are directly implemented by object designed to be added as session attributes.

The other listener interfaces are used to send events to objects that are not designed to be used as attribute.

Here is what I found about your question on http://www.pierobon.org/iis/url.htm:

The difference between the three is subtle. An URL refers to a Web page, including the scheme, but without a name location. An URN may also include the location of a code fragment. An URI refers to a Web page including the location of the code fragment, if one exists, and the scheme.
URL http://www.gleaners.org/faq.html
URN www.gleaners.org/faq.html#Q04
URI http://www.gleaners.org/faq.html#Q04

Because Web servers allow for default documents and do not require a scheme to retrieve a document, the subtle difference between an URL and an URN and an URI is hard to tell. URL is now used as the generic term.

Oups...

This interface is now deprected "As of Java Servlet API 2.4, with no direct replacement." (as said in the sun javadoc).

So, forget my former answer if you work with Servlet 2.4+ specification.

You are almost right.

The only thing I would add is the fact that your instance variables can be considered thread-safe if your servlet implements the SingleThreadModel interface.

About your first question, here is an excerpt from the HttpServletResponse javadoc:
public void sendError(int sc) throws java.io.IOException Sends an error response to the client using the specified status code and clearing the buffer. If the response has already been committed, this method throws an IllegalStateException. After using this method, the response should be considered to be committed and should not be written to.
It says that an IllegalStateException is thrown if the response has been commited before calling the sendError method (the same applies for sendRedirect). So, you are right when you say that no exception would be raised if you write something after one of these two method has been called.