You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by ji...@apache.org on 2004/04/17 19:07:33 UTC
[jira] Updated: (CACTUS-54) Preventing default session creation in some app servers
The following issue has been updated:
Updater: Vincent Massol (mailto:vmassol@apache.org)
Date: Sat, 17 Apr 2004 10:07 AM
Changes:
Fix Version changed to 1.7
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/CACTUS-54?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/CACTUS-54
Here is an overview of the issue:
---------------------------------------------------------------------
Key: CACTUS-54
Summary: Preventing default session creation in some app servers
Type: Bug
Status: Open
Project: Cactus
Components:
Framework
Fix Fors:
1.7
Versions:
1.5-beta1
Assignee: Cactus Developers Mailing List
Reporter: Jacques
Created: Tue, 9 Sep 2003 8:14 AM
Updated: Sat, 17 Apr 2004 10:07 AM
Environment: Operating System: Windows NT/2K
Platform: PC
Description:
Some application servers (eg. Atg Dynamo) automatically creates a session object
for each http request. This is not a normal scenario, however, the change
proposed below is harmless and enables us to integrate Cactus into such app
servers. Also see mailing list text pasted below.
CVS diff :
cvs diff -u
cvs server: Diffing .
Index: AbstractWebTestCaller.java
===================================================================
RCS file:
/home/cvspublic/jakarta-cactus/framework/src/java/share/org/apache/cactus/server/AbstractWebTestCaller.java,v
retrieving revision 1.23
diff -u -r1.23 AbstractWebTestCaller.java
--- AbstractWebTestCaller.java 12 Jul 2003 19:31:41 -0000 1.23
+++ AbstractWebTestCaller.java 9 Sep 2003 07:36:14 -0000
@@ -201,6 +201,12 @@
webImplicitObjects.getHttpServletResponse().setContentType(
"text/xml; charset=UTF-8");
+ // check if a session has been created, and invalidate it
+ if (webImplicitObjects.getHttpServletRequest().getSession(false) != null)
+ {
+
webImplicitObjects.getHttpServletRequest().getSession(false).invalidate();
+ }
+
try
{
Writer writer = getResponseWriter();
@@ -229,6 +235,11 @@
// Do not return any http response (not needed). It is enough to
// know this point has been reached ... it means the connection has
// been established !
+ // check if a session has been created, and invalidate it
+ if (webImplicitObjects.getHttpServletRequest().getSession(false) != null)
+ {
+
webImplicitObjects.getHttpServletRequest().getSession(false).invalidate();
+ }
}
/**
cvs server: Diffing runner
*****CVS exited normally with code 1*****
--- Vincent Massol <vm...@pivolis.com> wrote:
> From: "Vincent Massol" <vm...@pivolis.com>
> To: "'Cactus Users List'"
> <ca...@jakarta.apache.org>
> Subject: RE: question wrt session creation when
> running cactus from ant
> Date: Mon, 8 Sep 2003 21:30:10 +0200
>
> Ok. I understand better now. I think we can
> accommodate your change as
> it seems to be harmless (I just wanted to check the
> reason it was
> needed). Can you please enter a bugzilla bug report
> for that so that we
> don't forget it?
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: jacques [mailto:inspired_orange@yahoo.com]
> > Sent: 08 September 2003 10:52
> > To: Cactus Users List
> > Subject: RE: question wrt session creation when
> running cactus from
> ant
> >
> > Hi Vincent
> >
> > Got busy for a while on other things, hence the
> delay.
> > Yes, I agree that calling the server does not
> > automatically create a session - under normal
> > circumstances. However, we are using an
> application
> > server (Atg Dynamo) which always creates a session
> > object for every web request. Every http request
> > passes through a servlet pipeline (a linked list
> of
> > servlets) before the implementation class is given
> an
> > opportunity to interact. By that time a session
> has
> > already been created. It is the default behaviour,
> > which can be switched off, but I can unfortunately
> not
> > do that as the rest of the website depends on this
> > behaviour.
> >
> > I guess it is not reasonable to expect Cactus to
> > accomodate for every web server's own ways of
> > interacting with clients. I just thought that the
> > changes I proposed could do no harm (checking if a
> > session has been created, and if so invalidating
> it).
> >
> > Regards
> > Jacques
> >
> >
> > --- Vincent Massol <vm...@pivolis.com> wrote:
> > > Hi Jacques,
> > >
> > > See my other mail. Are you sure there are 3
> sessions
> > > per test created?
> > > I'd say there is one at most. Calling the server
> > > side does not
> > > automatically result in a session, you need to
> call
> > > getSession(true) to
> > > create a session, right?
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > -----Original Message-----
> > > > From: jacques
> [mailto:inspired_orange@yahoo.com]
> > > > Sent: 25 August 2003 16:06
> > > > To: cactus-user@jakarta.apache.org
> > > > Subject: question wrt session creation when
> > > running cactus from ant
> > > >
> > > > Hi there
> > > >
> > > > I am having problems with the amount of http
> > > sessions
> > > > that are created when cactus is invoked from
> ant.
> > > It
> > > > looks like for each test run ant (using the
> > > <cactus>
> > > > task) call the web server once, to check that
> it's
> > > > running. Something like :
> > > >
> > > >
> > >
> >
> /cactification/ServletRedirector?Cactus_Service=RUN_TEST
> > > > HTTP/1.1
> > > >
> > > > Then, for each test method, 2 seperate http
> calls
> > > are
> > > > made. One to request the servlet redirector to
> > > execute
> > > > the test, and one to request the result.
> Something
> > > > like :
> > > >
> > > >
> > >
> >
> /cactification/ServletRedirector?Cactus_TestMethod=testSetContentTypeHea
> > > de
> > > >
> > >
> >
> r&Cactus_TestClass=org.apache.cactus.sample.unit.TestHttpHeaders&Cactus_
> > > Au
> > > > tomaticSession=false&Cactus_Service=CALL_TEST
> > > > HTTP/1.1
> > > > and...
> > > >
> > > >
> > >
> >
> /cactification/ServletRedirector?Cactus_Service=GET_RESULTS
> > > > HTTP/1.1
> > > >
> > > > These 2 calls (and thus request objects) cause
> 2
> > > http
> > > > sessions to be created on the application
> server.
> > > Of
> > > > the 2, I have access to one (the one that
> makes
> > > the
> > > > test call) and can invalidate it in the
> tearDown.
> > > That
> > > > leaves me with 1 redundant session (the one
> > > associated
> > > > with the result request). One session on the
> app
> > > > server for each test method run. I have 276
> test
> > > > methods that I need to run, and only a 20
> session
> > > > developer license. My problem (and therefore
> my
> > > > question) is quite obvious : How can I get
> access
> > > to
> > > > the request that's made in the second call, so
> > > that I
> > > > can call getSession(false).invalidate() on it
> ?
> > > >
> > > > Jacques
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > The New Yahoo! Search - Faster. Easier. Bingo.
> > > > http://search.yahoo.com
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > cactus-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > cactus-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > cactus-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > cactus-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free, easy-to-use web site
> design software
> > http://sitebuilder.yahoo.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> cactus-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> cactus-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org