HttpServletRequest attributes

X-Application Version: 3.1.3
Tamino Version :
Platform : Win2k
WebContainer : Tomcat 3.3
JDK Version : 1.3.1

Hi, I set a request attribute in one x-application generated JSP page, but in the destination page(also a JSP genereated by x-application) I cannot get that request attribute. What is the reason?

I use JSP scriptlets like the following,

<% request.setAttribute(…); %>


if (request.getAttribute(…) != null) {



I am not the JSP and Servlet specialist and there may be someone who can give a more precise answer to your problem. My understanding of the Servlet class is that the state of request object is not persistent during a session, means for each request you send a new request object is created. In this way, attributes you set for the current request are lost when receiving the next one. For holding information over multiple requests you should use the session object where also X-Application stores its context object.

What kind of attributes do you want to set?

Is it data to control you application logic or do you want to influence the behavior of the request object (e.g. for encoding parameters)?


Did you try to set an attribute in the session object? These attributes should be available on the next page.

If I remember correctly, it done like this:

pageContext.getSession().setAttribute(“attrName”, “myValue”)


Software AG Germany, Darmstadt

Thank you both, Christian and Michael.

In fact what I wanted to do is to set an attribute in a request to the next JSP page, but not in a session. This way, that attribute won’t be remembered after another request. This is part of the effort I make to control the application logic.

I think X-Application enables variable setting and retrieval through xapp:setvar... and xapp:getvar..., but it only allows two scopes, namely “page” and “session”, respectively. And it lacks support for the scope “request” and “application” that’re supported by Sun’s servlet and JSP standard.

I’ll try to find some clue in Tamino x-application Java API.

Thanks again, Christian and Michael.