jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Mattern" <mmatt...@web.de>
Subject Re: Cactus and BroadVision 6.0?
Date Sun, 30 Jun 2002 20:50:01 GMT
Hi Vincent,

> I don't really understand what is your problem. You have a servlet
> container (Broadvision) which implements the Servlet API, right ? Thus,
> from the point of view of your servlet code, there should be no
> difference whether your servlet is run in Tomcat or in Broadvision.

Yes, that's what I'd think as well. It's just that the sample-servlet that's
coming with Cactus runs just fine on Tomcat and fails all test on BV
(because the responses are empty).

> To answer your question, it is your servlet code that initially creates
> the HttpSession. The Servlet API has a
> HttpServletRequest.getSession(boolean) API. If the boolean is true and a
> session does not already exist, then a new session will be created by
> the container and returned by getSession. The container knows a session
> already exist by getting the session id from a cookie in the HTTP
> request (or from a URL parameter, that's called URL rewriting). The
> servlet API says that the cookie is named jsessionid (the value
> associated with the cookie is unique), so the the container will look
> for that cookie. If it finds it, it will then look in its hashtable of
> session for a matching HttpSession object.
> The ServletRedirector will call getSession(true) by default, thus
> letting the BV container creates an HttpSession.

Okay, so that might explain why the parameter is added. Actually,
BVHttpServletRequest.getSession(boolean) ignores the argument and does the
same as BVHttpServletRequest.getSession(): It just returns its _session
attribute, which is a BVHttpSession. If I understand you correctly, the BV
implementation fails to align to the standard here, and this might be the
reason why it doesn't work? So maybe I could extend the Cactus
ServletRedirector and try to set up the BV session where the
HttpServletRequest.getSession(true) call is made?

> > The second thing I still don't know is: Who puts the
> > "com.broadvision.session.new" parameter into the query string? My
> guess
> > after JAD has done its job is that it happens deep inside BV and not
> > within
> > the servlet engine.
> Look at the source of the HTML pages returned by BV. Do you see this
> parameter being passed whenever there is a link ? When you write a JSP,
> do you use a special API to create links ?

When I'm surfing a BV site (without Cactus), I can see that BV rewrites the
URLs to keep the session ID, visitor ID (BV's user ID), etc., but the
"com.broadvision.session.new" parameter is never there.
And when I run the Cactus sample-servlet test cases, the results BV returns
are always empty.

> BV cannot put that parameter alone. You, as the Servlet/JSP writer is
> either putting it or not putting it.

I guess that it is implicitly set because the session is not set up like BV
expects it. I haven't tried to run a test on one of our "real" JSPs/servlets
with Cactus because the sample-servlet tests all failed.

> > Whatever object does this seems to signal that no BV
> > session has been set up for the current HTTP connection.
> Unfortunately,
> > there is no documentation about all this (otherwise, JAD wouldn't have
> > been
> > necessary in the first place...).
> >
> > I guess that you have become familiar with a great many different
> servlet
> > engines and their specifics, so: What would you advice me to do? Where
> > should I look next? Is there any information I can provide you with so
> > that
> > you can tell me why Cactus isn't working with BV and what can be done
> > about
> > it?
> Yes. You have not told us what error you were getting and for what test
> from sample-servlet. Can you post the stack trace ? (both client side
> and server side).

Okay, I will do that.



To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>

View raw message