Benny Bräuer wrote:
Hi Rainer,
I'm using a single node. Here's some code from the servlet:
<code>
HttpSession session = request.getSession(false);
if(session.getAttribute("aValueSavedInThePortlet") != null) {...}
else {...}
</code>
I get a correct NullPointerException, because "session" is empty. So,
back to the problem: Using the real Tomcat-url to call portal
container and then calling the servlet within its portlet works fine,
"session" is not null. Using the "Apache/mod_jk"-url to do this
returns the NullPointerException because of the empty session. Kindly
note that I can't use "request.getSession(true);" in this case, I
can't allow the action in the if statement without a valid session
was generated in the portlet container before.
So I think the problem is the session which is bound to the Tomcat-url
(foo.bar.com:8080) and do not not to the virtual-host / alias url
(www.foobar.com) of the Apache with mod_jk.
Before the long explanations, a short question:
Do you have set any JkOptions of the type Forward... in your Apache
configuration? Especially ForwardURIEscaped will break URL encoded
sessions up until (iuncluding) mod_jk 1.2.24. It's fixed now in 1.2.25.
It's not likely, that that's your problem, but you should check.
There are two basic facts related to sessions, which might help you to
understand what's going on:
- a session usually is bound to a context, in other words to a web app.
So you always need to understand, which webapp you are sending your
requests to. This gets more complicated, once cross context calls get
used, but I think this is not the case in your situation.
- how does the container know, which session a request belongs to? Two
sub cases:
- Using a cookie: whenever a new session is created, a cookie is
sent back to the browser. The cookie is called JSESSIONID. It contains
the name of the server and a URL prefix (the webapp name mentioned
above) to describe, for which future requests this cookie is valid, and
it contains the session id as payload information. Whenever the browser
sends a future request which goes to a system and URL, that fits the
validity rules, it automatically includes a JSESSIONID cookie with the
stored session id as value. You can easily check the cookies your
browser knows about and their validity in all modern browsers. Cookies
can be disabled in the browser by the user, sometimes even for special
sites, usually they are enabled. A webapp uses a cookie, if you do not
disable it by Tomcat configuration.
- Using URL rewriting: in contrast to cookies, this method is not
transparent to the webapp, i.e. the webapp developer needs to wrap all
URLs used inside the content, which need to point back to the session,
in an encodeURL() call. The container will then add a suffix of the form
";jsessionid=..." to the URL, where "..." is the session id. Such a URL
manipulation can be easily seen in the URL display of the browser (at
least if it is not hidden by using frames).
mod_jk will forward Cookies as well as URL prefixes. In a non
load-balancer situation I see no reasons for problems, but the above
might help you in finding the reason for your problem.
I apologize for my English, I'm still learning.
No problem, me too :)
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
