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. Thanks, Michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
