Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!

Gabriel Forro

Ranch Hand
+ Follow
since Apr 16, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Gabriel Forro

Hi Aniket,

The answers are as follows:
1. Yes, there is a default buffering. According to the JSP spec (page 50):

The default is buffered with an implementation buffer size of
not less than 8kb.

It means that the exact buffer size is implementation dependent (it can vary from vendor to vendor)
2. Yes it does
3. The part you quoted is from the "Dynamic content type" section of the JSP specification. The whole quote:

Dynamic setting of content type relies on an underlying invocation on response.setContentType(). That method can be invoked as long as no content has been been sent to the response stream. Data is sent to the response stream on buffer flushes for buffered pages, or on encountering the first content (beware of whitespace) on unbuffered pages.

Imagine that You switched off the buffering. In this case a whitespace which is placed just before the dynamic content commits/sends the response to the client. So You can not call the response.setContentType() any more! So You must beware of the whitespaces if You want to call the setContentType() method in an JSP page.
Try the scarab. It is quite simple and effective.

the option 2 is correct.
The explanation is as follows:

1. It is a JSP file

2. If there is no <%@ page session="false" %> explicitly, then session is set to true by default. It means, that the session object is created before the very first line of the JSP page (in the jsp's servlet class definition).

here is the explanation from the JSP 2.0 spec (page 174):

The tag file implementation must create and maintain a second instance of
JspContext called a JSP Context Wrapper. If the Invoking JSP Context is an
instance of PageContext, the JSP Context Wrapper must also be an instance of
PageContext. This wrapper must be returned when getJspContext() is called.

For each invocation to the tag, the JSP Context Wrapper must present a clean page scope containing no initial elements. All scopes other than the page scope must be identical to those in the Invoking JSP Context and must be modified accordingly when updates are made to those scopes in the JSP Context Wrapper. Any modifications to the page scope, however, must not affect the Invoking JSP Context. there is a new JspContext (PageContext) for the tag file.

I think, that there is no built-in way to access the servlet init parameters through EL.
If You do not want to use scripting:
1. You can create an EL function, which takes the ServletConfig object and the name of the init parameter as a String object and returns the value of the init parameter.
2. You can create a custom tag

The JSTL lib (2 jar files, i.e. jstl.jar and standard.jar) is included in the Tomcat distribution.
You can find it in
If You want to use JSTL in Your web application, there are 2 ways:
1. copy the above mentioned 2 jar files to the ${CATALINA_HOME}/shared/lib directory, and every web application deployed can use them.
2. copy the above mentioned 2 jar files to the WEB-INF/lib directory of Your web application. In this case the JSTL lib is "private" for the web application.

Tomcat is a very friendly container. The XML validation is switched off by default. If You check the
xml schema, You can notice, that the body-content is not an optional element.
In my opinion if You use <taglib ... version="2.0">, than there is no default value for the classic and simple tags, as the tld file is invalid without a <body-content> element.

The body-content element's definition from the

If You use older version of tld (validated by
), where You can use only classic tags, then the default value is JSP. This is the case for older tag libaries.

For the 1.4 exam You have to know the JSP 2.0 spec.
[ December 15, 2004: Message edited by: Gabriel Forro ]

I think, You are not correct regarding simple and classic custom tags.

In the JSP 2.0 spec the <body-content> element is mandatory in the tld file for the simple ang classic custom tags. So there is no default value.

imagine You have a request attribute:

if You use:

, there will be a javascript block on the client side.

But if You use:

the text will be text and not javascript code. Thanks to the escaping.
So the answer is, that cross-site scripting attack is not prevented in EL. You can use the

tag to prevent it.

[ December 13, 2004: Message edited by: Gabriel Forro ]

[ December 13, 2004: Message edited by: Gabriel Forro ]
[ December 13, 2004: Message edited by: Gabriel Forro ]

the Bean's code is all right. There is a no arg constructor, so it should be compiled without any error (You can call another constructor by the this(...) expression from the very first line of the constructor)

The final value of myProperty should be an ampty string. The reason is, that You have used the <jsp:setProperty.../>'s value form, where value is an empty string.

yes, D is the correct answer.

every listener should be registered in DD except HttpSessionBindingListener.

I put my tips to the:
15 years ago

I have used the "HF Servlets and JSP" (read twice) and study the specs as well (mainly jstl core and custom tags). On the last day I went through the JSP and servlet API also to memorize the method signatures, names and return values.
In my opinion the HF Servlets and JSP is enough for the exam. In addition to the info in the book You have to know something about dynamic attributes for the custom tags (it is not covered in the book). The HFSJ is a great book, but be aware, as there are some mistakes. The ones I can remember:

the exception JSP object is Throwable and not JspException
If the argument of the sendRedirect, encodeURL, encodeRedirectURL methods begins with '/', than it is a relativ to the container's root (not to the web application's root)
the <c:remove var="attr"/> removes all attributes 'attr' from all scopes.
${aBean.notAProperty} throws an exception, if aBean is not null and there is not any 'notAProperty' property on the bean.

is not valid. The security-role tag can contain only one role-name tag. So the

is the right one.

In addition to the reading I have created a lot of small web applications on my laptop to try everything what I have read. That is all

Yesterday was the big day. It was quite successful
The JavaRanch's community, so You also, who is reading this line, helped and supported me. Thanks for it!