Ah, I see what is going on... What's happening is kind of not
recommended architecture.
This property:
<property name="sessionFacade" type="properties.SessionProperty" />
Extends the MachII.framework.Property construct. Because this is a
framework extension, we set this property name of "sessionFacade" as a
"configurable property", however this property then creates a session
facade and sets it into the Mach-II as a property named
"sessionFacade". So what is happening is that you are replacing the
"sessionFacade" property with a non-configurable property later on at
runtime. Essentially, you're swapping in a non-Mach-II extended
component into a slot that the framework marked as "Mach-II configurable".
I'd recommend not using a Mach-II property CFC to load a non-Mach-II CFC
in the same Mach-II property name. You could easily fix the issue by
changing:
<property name="sessionFacade" type="properties.SessionProperty" />
To this:
<property name="sessionFacadeLoader" type="properties.SessionProperty" />
Your "loader" will still function the same and place a reference to your
"real" session facade into the "sessionFacade" property.
HTH,
.Peter
P.s. Your cfparams will only be run once when the session facade loads
because your session facade is a singleton. If you want to set those
session variables when a new session starts, I'd recommend looking at
the onSessionStart() plugin point in Mach-II. You don't have to set the
variables in that plugin point, but at least have the plugin point call
an "onSessionStart()" method in your session facade. In your plugin you
can do this:
<cffunction name="onSessionStart">
<cfset getProperty("sessionFacade").onSessionStart() />
</cffunction>
In you session facade, add this:
<cffunction name="onSessionStart">
<cfset session.mycaptcha = "" />
<cfset session.UpdateProfile = false />
<cfset session.UpdatePassword = false />
</cffunction>
This is just pseudo code, but I think you can get the picture. I think
you're random error you might be seeing might has to do with missing
session variables. Just a guess since I haven't seen the exception.
Summer Wilson said the following on 11/01/10 11:44:
Yes, I think so. Here are the relevant bits of code (I think). Oh, I
also found that the error is somewhat random. It will error on a
page...then sometimes you reload, it loads fine, then back again.
From mach-ii.xml
<!-- sessionFacade - to control session and keep it separate from
framework and MVC -->
<property name="sessionFacade" type="properties.SessionProperty" />
Session.Property.cfc
<cfcomponent displayname="SessionProperty"
extends="machII.framework.Property" output="false">
<cffunction name="configure" access="public" output="false">
<!--- create the sessionFacade and store it in the property mgr --->
<cfset var sessionFacade =
createObject("component","model.SessionFacade").init() />
<cfset setProperty("sessionFacade", sessionFacade) />
</cffunction>
</cfcomponent>
The top bit of SessionFacade.cfc
<cfcomponent displayname="SessionFacade" hint="Basic Session Facade"
output="false">
<cfparam name="session.mycaptcha" default="" />
<cfparam name="session.UpdateProfile" default="false" />
<cfparam name="session.UpdatePassword" default=false />
<cffunction name="init" returntype="SessionFacade" access="public"
output="false">
<cfreturn this />
</cffunction>
......
</cfcomponent>
~~ Summer AKA Collectonian
On Mon, Jan 11, 2010 at 11:36 AM, Peter J. Farrell <[email protected]
<mailto:[email protected]>> wrote:
Does this session facade component that is throwing the error
extend MachII.framework.Property? Would you mind sharing that
code? Feel free to email me off list if you don't want to share
it with the world. If it is not extending the framework
extension, there is no way for us to call deconfigure() since that
method is inherited.
Best,
.Peter
Summer Wilson said the following on 11/01/10 11:03:
Correction, I did find the XML config file had<!DOCTYPE mach-ii
PUBLIC "-//Mach-II//DTD Mach-II Configuration 1.6.0//EN"
"http://www.mach-ii.com/dtds/mach-ii_1_6_0.dtd";>
So I changed it to<!DOCTYPE mach-ii PUBLIC "-//Mach-II//DTD
Mach-II
Configuration 1.8.0//EN"
"http://www.mach-ii.com/dtds/mach-ii_1_8_0.dtd";>
and<mach-ii version="1.6"> has been changed to<mach-ii
version="1.8">
cleared the template cache again and restarted the server again -
still getting the error
~~ Summer AKA Collectonian
On Mon, Jan 11, 2010 at 10:40 AM, Summer
Wilson<[email protected] <mailto:[email protected]>>
wrote:
Nope, there are no version mappings at all. 1.6 was
deleted off the server entirely before loading 1.8. We
only have the one MachII folder on the server.
~~ Summer AKA Collectonian
On Mon, Jan 11, 2010 at 10:31 AM, Peter J.
Farrell<[email protected] <mailto:[email protected]>> wrote:
Is there a 1.6 version mapping setup for your
application or another version in another folder on
the service? I suspect that parts of 1.8 are being
loaded from one version and parts of 1.6 are loaded
from that version. CF's dot path resolution for CFCs
uses a lists of places to look and that is probably
what is going on here. I doubt there is a Mach-II
code issue otherwise I think we would have seen it
about a year ago when this deconfigure() was added to
the one 1.8 code base.
.Peter
Summer Wilson said the following on 11/01/10 08:18:
Okay. The upgrade instructions pretty much just said
to clear template cache and restart the server. I did
both and still getting the same error. When I did the
upgrade, I completely deleted the 1.6 folder first,
then uploaded 1.8 in its place, to ensure it was clean.
~~ Summer AKA Collectonian
On Sun, Jan 10, 2010 at 1:15 AM, Peter J.
Farrell<[email protected] <mailto:[email protected]>>
wrote:
They are in the file called README in the root of
the framework bundle.
.pjf
Summer Wilson said the following on 10/01/10 00:59:
Ah, no, I didn't...where are the upgrade
instructions? :-P
~~ Summer AKA Collectonian
On Sat, Jan 9, 2010 at 11:32 PM, Peter J.
Farrell<[email protected]
<mailto:[email protected]>> wrote:
If you session facade extends the
MachII.framework.Property -- then Mach-II will
call deconfigure for you (it's in the
MachII.framework.BaseComponent if you don't
define it). Did you follow the upgrade
instructions that come with the framework?
More than likely your CFML engine is caching
some CFCs from the 1.6 version which is
causing the problem or possible based on how
you've deployed Mach-II -- there could be two
versions on your system and at runtime they
are being mixed. I bet if you go back over
the upgrade instructions -- I have a feeling
this stuff will get resolved. Let us know
what happens -- I want to be sure it's all
working for you.
Best,
.Peter
--
You received this message because you are subscribed
to Mach-II for CFML list.
To post to this group, send email to
[email protected]
<mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>
For more options, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
--
You received this message because you are subscribed to Mach-II
for CFML list.
To post to this group, send email to
[email protected]
<mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>
For more options, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
--
You received this message because you are subscribed to Mach-II for CFML list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
