Ah.  What happens when you comment out the <cfheader> tags?         
Apache has a module called mod_cache (http://httpd.apache.org/docs/ 
2.2/mod/mod_cache.html).  You might check to see that the settings  
are the same on both servers - especially the  "CacheStoreNoStore"  
setting which overides the caching directives in the header - since  
it's behaving differently between different installations of Apache.

When you say your default event is firing do you mean the <result  
do="template"> to the base event template or are you referring to a  
duplication of the entire event context with all results, broadcasts,  
etc.      Can your MG debug output help you tell where in the code  
it's firing the duplication?   Since MG builds the Event Context  
sequentially outward from the intial event handler, it may help you  
track down where the issue is occurring.

MG creates a conditional loop  to watch for the existence of named  
results in your event-handlers so it may be that one of these results  
conflicts with another value or isn't there.   It might be that this  
loop isn't being completed somehow and, depending on the XML in your  
event handler  (i.e. - you only have a named results in your XML for  
the "do"), is firing again.

I'm still going to go out on a limb and say it's something in the way  
your client/cftoken variables are being set and handled between the  
browsers and the MG behavior you're seeing has something to do with  
those.    That's just my gut feeling, though, since I don't know your  
application.

HTH,

Jon

On May 1, 2007, at 6:01 PM, [EMAIL PROTECTED] wrote:

> Jon,
>
> Thanks for your reply...
>
> I initially didn't think this problem had much to do with Model-Glue
> but then I examined the debug output and saw that the default event is
> being fired multiple (i.e. more than once) times (the default event is
> where the session objects are being instantiated), even when an event
> is defined, so I'm confused here.  I am using Apache on the dev laptop
> and staging server and this was a brand new install of both Apache and
> ColdFusion on the stage server, so when I first noticed this problem I
> also realized that we forgot to set index.cfm as the directory index
> in the apache httpd.conf file. We then set index.cfm as the directory
> index thinking that would resolve the problem but no such luck.
> Perhaps there is something else to look at on the web server? The
> development web server uses named virtual hosts, and the root
> directory for the application has the same name on both development
> and stage. All application files (model, view, controller) are stored
> outside the web root with only index.cfm and Application.cfm in the
> web root.
>
> The staging server does not use SSL but the production server will.
>
> The setdomaincookies attribute of the cfapplication tag is not  
> defined.
>
> I have the views set to not cache using the following:
> <cfheader name="expires" value="#now()#" />
> <cfheader name="cache-control" value="no-cache, no-store, must- 
> revalidate" />
>
> There is no usage of cfcookie.
>
> Again, many thanks for trying to help.
>
> Nate
>
>
> Quoting Jon Clausen <[EMAIL PROTECTED]>:
>
>> Nate,
>>
>> I don't think it's a Model Glue related issue based on the browser-
>> specific issues you are encountering.    At first blush it sounds
>> like a Web Server configuration issue or maybe something with the
>> handling of cfide/cftoken variables.  Are you using SSL at all on the
>> staging server?      There are some caching differences between IE
>> and the others with SSL.
>>
>> IMHO it may be an issue with your client and/or session variables in
>> general, if the application is re-creating the session (thereby re-
>> instantiating your objects), have you checked the following:
>>
>>   - cfapplication tag has setdomaincookies="false". If you have this
>> as false, it might explain the problem since the CF token cookies are
>> being set and CF can't follow the user properly.    If you're
>> development domain is "localhost", you sometimes won't notice these
>> differences until you move it to a remote machine.
>>
>> - usage of CFCookie  for any variables which CF would normally
>> handle.  If CFCookie was used to set or override variables that were
>> handled by CF, the writing of these variables may be causing
>> overwriting of session ids as well.
>>
>> IE tends to be a bit fussier in allowing the webserver to do multiple
>> writes per request on cookies so you may not be seeing the issues in
>> IE because of this.
>>
>> HTH,
>>
>> Jon
>>
>> P.S. - There is one Model Glue related thing I can think of:    is
>> the directory name for the root of your project different on the
>> staging server from your development machine?   MG (Unity at least
>> and I believe 1.1 as well) uses that directory name to set it's
>> "application[ModelGlue_APP_KEY].framework" variables by default.
>> If your application uses that Struct Key at all, it could be that  MG
>> can't find the key correctly on concurrent requests re-instantiates
>> some objects.   Seems like that would throw CFErrors in most cases I
>> can think of, but it's worth a look...
>>
>>
>> On May 1, 2007, at 3:52 PM, Nate Petersen wrote:
>>
>>> Hello all,
>>>
>>> I posted this previously to the model-glue site's message board and
>>> also to the model-glue list here and didn't get any action, so I
>>> hope someone here can help.
>>>
>>> So after working for the last couple months on my first Model-Glue
>>> application, I
>>> finally have it ready for some wider-scale testing. So I move the
>>> code from my
>>> development machine (windows laptop, where the application is
>>> running smoothly and completely as expected on both FireFox and
>>> IE), to my staging server (sun solaris box) where things start to
>>> go south a bit. When testing the application from the staging
>>> server it runs smoothly and as expected using IE, but in Firefox
>>> (and Safari) it's not so smooth. The default event which
>>> initializes several objects in the session scope appears to be
>>> running multiple times on every other event/request (according to
>>> the Model-Glue debug output), therefore effectively killing and re-
>>> initializing the session based objects on each request! I am
>>> pulling my hair out on this one... I can't understand why it's
>>> isolated to Firefox/Safari when coming from the staging server. I
>>> have tested with 3 different machines (two PC's and one Mac) and
>>> all yield the same crazy results when running the application from
>>> the staging server in Firefox or Safari. The only significant
>>> difference between servers (aside from the fact that it is moving
>>> from Windows to Unix) is that the staging server is running CF 7.02
>>> and the laptop is running CF 7. I am using Model-Glue 1.1. Can
>>> anyone point out anything that I might be overlooking? Any other
>>> suggestions? I am kind of desperate.
>>>
>>> Many thanks,
>>>
>>> Nate Petersen
>>
>>
>>
>
> 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Upgrade to Adobe ColdFusion MX7
The most significant release in over 10 years. Upgrade & see new features.
http://www.adobe.com/products/coldfusion?sdid=RVJR

Archive: 
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:276714
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4

Reply via email to