Ok, I've got sample code and log file dumps. The good news is that the
behavior is consistent on both CF8 and OpenBD 1.2. The bad thing is
that I don't understand why the

<cfset this.sessionTimeout = CreateTimeSpan(0,0,application.ST,0) />

doesn't appear to be working on either.

The sample code consists of two files, an application.cfc (below) and
a blank index.cfm:

------------------------------------------------------------
<cfcomponent name="Application" displayname="Test" output="true" >
        <cfset this.name = "TestApp">
        <cfset this.applicationTimeout = CreateTimeSpan(0,2,0,0)>

        <cfparam name="application.ST" default="20">

        <cfset this.sessionManagement = "true">
        <cfset this.sessionTimeout = CreateTimeSpan(0,0,application.ST,0) />

        <!---
================================================================================================
--->
        <cffunction name="onSessionStart" returnType="void" output="true">

                <cflog text="session has started #now()# with a timeout of
#this.sessionTimeout# (#(this.sessionTimeout * 24 * 60)#m)" />
                <cfif StructKeyExists(application,"sessionTimeout")>
                        <cflog text="application.ST is currently 
#application.ST#" />
                <cfelse>
                        <cflog text="'ST' does not exist in the application 
scope yet,
bucko.">
                </cfif>

        </cffunction>

        <!---
================================================================================================
--->
        <cffunction name="onSessionEnd" returnType="void" output="true">
                <cfargument name="SessionScope" required="true" />
                <cfargument name="ApplicationScope" required="true" />

                <cflog text="session has ended #now()#" />

        </cffunction>

        <!---
================================================================================================
--->
        <cffunction name="onRequest" returntype="void" output="true">
                <cfargument name="targetPage" required="true">

                <cfif StructKeyExists(url,"time")>
                        <cfset this.sessionTimeout = 
createTimeSpan(0,0,url.time,0) />
                        <cfset application.ST = url.time />

                        <cflog text="timeout updated #now()# with a timeout of
#this.sessionTimeout# (#(this.sessionTimeout * 24 * 60)#m)" />
                        <cflog text="application.ST is currently 
#application.ST#" />
                <cfelse>
                        <cflog text="new request at #now()# but timeout remains
#this.sessionTimeout#" />
                        <cfif StructKeyExists(application,"ST")>
                                <cflog text="application.ST is currently 
#application.ST#" />
                        <cfelse>
                                <cflog text="'ST' does not exist in the 
application scope yet,
bucko.">
                        </cfif>
                </cfif>

                <cfoutput>
                        The request has started, timeout is: 
#this.sessionTimeout#,
                        <cfif StructKeyExists(application,"ST")>
                                w application sessionTimeout of #application.ST#
                        <cfelse>
                                w/o an application scope variable to set things
                        </cfif>

                        <br />
                        <a href="?#createUUID()#">New Request?</a>
                </cfoutput>
        </cffunction>


</cfcomponent>
------------------------------------------------------------


The steps to reproduce are as follows:
1) hit the index.cfm file (upon enter, the timeout and application
timeout will still be the default in the admin screen, regardless of
what's on top of the application.cfc)
2) click on the "new request" link, resetting the request (upon enter,
the timeout and application timeout will still be the default in the
admin screen, regardless of what's on top of the application.cfc)
3) change the url to remove the UUID and replace it with
"time=5" (upon enter, the stated session timeout will be correct, with
application variable equal to 5)
4) click on the "new request" link again (the session timeout will
again be the default in the xml file or admin screen, even though the
application variable is correctly set and should be used to set the
timeout in the application.cfc psuedo constructor)

also odd is that both openBD and CF8 the cfparam statement at the top
of the application.cfc file doesn't not seem to be used at all to
created a default value in the application scope.

Finally, the log output:

==================
CF8
------------------
"Severity","ThreadID","Date","Time","Application","Message"
"Information","jrpp-1","08/26/10","21:04:26",,"C:\ColdFusion8\logs
\application.log initialized"
"Information","jrpp-1","08/26/10","21:04:26","TESTAPP","session has
started {ts '2010-08-26 21:04:26'} with a timeout of 1200 (1728000m)"
"Information","jrpp-1","08/26/10","21:04:26","TESTAPP","'ST' does not
exist in the application scope yet, bucko."
"Information","jrpp-1","08/26/10","21:04:26","TESTAPP","new request at
{ts '2010-08-26 21:04:26'} but timeout remains 1200"
"Information","jrpp-1","08/26/10","21:04:26","TESTAPP","'ST' does not
exist in the application scope yet, bucko."
"Information","jrpp-1","08/26/10","21:04:36","TESTAPP","new request at
{ts '2010-08-26 21:04:36'} but timeout remains 1200"
"Information","jrpp-1","08/26/10","21:04:36","TESTAPP","'ST' does not
exist in the application scope yet, bucko."
"Information","jrpp-1","08/26/10","21:04:50","TESTAPP","timeout
updated {ts '2010-08-26 21:04:50'} with a timeout of 0.00347222222222
(5m)"
"Information","jrpp-1","08/26/10","21:04:50","TESTAPP","application.ST
is currently 5"
"Information","jrpp-1","08/26/10","21:05:11","TESTAPP","new request at
{ts '2010-08-26 21:05:11'} but timeout remains 1200"
"Information","jrpp-1","08/26/10","21:05:11","TESTAPP","application.ST
is currently 5"
==================


==================
OpenBD 1.2
------------------
26/08/10 20:58.12: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; session has started {ts
'2010-08-26 20:58:12'} with a timeout of 0.0138888888889 (20m)
26/08/10 20:58.12: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; 'ST' does not exist in the
application scope yet, bucko.
26/08/10 20:58.12: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; new request at {ts '2010-08-26
20:58:12'} but timeout remains 0.0138888888889
26/08/10 20:58.12: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; 'ST' does not exist in the
application scope yet, bucko.
26/08/10 20:58.21: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; new request at {ts '2010-08-26
20:58:21'} but timeout remains 0.0138888888889
26/08/10 20:58.21: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; 'ST' does not exist in the
application scope yet, bucko.
26/08/10 20:59.10: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; timeout updated {ts
'2010-08-26 20:59:10'} with a timeout of 0.00347222222222 (5m)
26/08/10 20:59.10: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; application.ST is currently 5
26/08/10 21:00.49: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; new request at {ts '2010-08-26
21:00:49'} but timeout remains 0.0138888888889
26/08/10 21:00.49: Information; TestApp;
thread[14746...@qtp-28168925-7,5,main]; application.ST is currently 5
------------------

That's a very long winded way of saying "why is my
'this.sessionTimeout'" continually being overridden by the server
default? If I set this one line and only this one line to anything
other than the server default the log file still shows the timeout is
being the server default. Am I missing something?

-- 
Open BlueDragon Public Mailing List
 http://www.openbluedragon.org/   http://twitter.com/OpenBlueDragon
 official manual: http://www.openbluedragon.org/manual/
 Ready2Run CFML http://www.openbluedragon.org/openbdjam/

 mailing list - http://groups.google.com/group/openbd?hl=en

Reply via email to