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 "Vincent Massol (JIRA)" <ca...@jakarta.apache.org> on 2005/01/27 22:17:18 UTC
[jira] Updated: (CACTUS-54) Preventing default session creation in some app servers
[ http://issues.apache.org/jira/browse/CACTUS-54?page=history ]
Vincent Massol updated CACTUS-54:
---------------------------------
Fix Version: (was: 1.7)
> Preventing default session creation in some app servers
> -------------------------------------------------------
>
> Key: CACTUS-54
> URL: http://issues.apache.org/jira/browse/CACTUS-54
> Project: Cactus
> Type: Bug
> Components: Framework
> Versions: 1.5-beta1
> Environment: Operating System: Windows NT/2K
> Platform: PC
> Reporter: Jacques
>
> 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
> >
--
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