Pete Pommelich

Hi,

calling include method of the PageContext has the same effect -as the answerd indicate- as calling the include method of the RequestDispatcher or using the jsp:include action. From the API

Causes the resource specified to be processed as part of the current ServletRequest and ServletResponse being processed by the calling Thread. The output of the target resources processing of the request is written directly to the ServletResponse output stream.

The current JspWriter "out" for this JSP is flushed as a side-effect of this call, prior to processing the include.

If the relativeUrlPath begins with a "/" then the URL specified is calculated relative to the DOCROOT of the ServletContext for this JSP. If the path does not begin with a "/" then the URL specified is calculated relative to the URL of the request that was mapped to the calling JSP.

And pageContext is a implicit object available in a JSP.

Correct me if I'm wrong.

Kind regards,

Hi, Chandan,

sorry, I made a mistake. The IDE I use for testing didn't print the the exceptions to the output window. So I assumed that the my valueUnbound method was never called.

Kidn Regards

Hi,

are you sure that valueUnbound is called when a attribute is replaced? For me the the part of the API sounds like valueUnbound is only called when the attribute is removed. I tried a little example that seems to confirm this. So I'm wondering why the valueUnBound method in the example above is called. Or am I completely wrong?

Hi,

it depends if you get the RequestDisptacher from the ServletRequest or from the SverletContext. If you use the ServletContext, e.g.
RequestDispatcher view = getServletContext().getRequestDispatcher("/index.jsp");
the String has to start with a slash.

The pathname must begin with a "/" and is interpreted as relative to the current context root. Use getContext to obtain a RequestDispatcher for resources in foreign contexts. This method returns null if the ServletContext cannot return a RequestDispatcher.

If you use the request the String might start with a slash, but it doesn't have to (depending on the current dir etc.):
RequestDispatcher view = request.getRequestDispatcher("index.jsp");

The pathname specified may be relative, although it cannot extend outside the current servlet context. If the path begins with a "/" it is interpreted as relative to the current context root. This method returns null if the servlet container cannot return a RequestDispatcher.

So, answer D

If second <aurth-constraint> element is removed, the constrained resource can be accessed by both the roles.

is still correct, isn't it?

Hi,

I don't understand this yet. If we have the following part of the DD
<auth-constraint> <role-name> student <role-name> </auth-constraint> Second security constraint has: <auth-constraint/>

And we remove the second <auth-constraint/>, the above DD part is equal to the following
<auth-constraint> <role-name> student <role-name> </auth-constraint> Second security constraint has: <auth-constraint> * </auth-constraint>
(see page 669 2nd Edition) which means, everbody can make a request for the constraint resource. Or am I wrong?

Kind Regards,
Pete