Using trunk ICEfaces, and running the showcase, which uses an h:commandButton, I can't reproduce this in Chrome. Can you please try with either an h:commandButton or with the most recent HEAD of trunk to see if this problem still exists in you app?

http://anonsvn.icesoft.org/repo/icefaces3/trunk/icefaces/

That is, I tested using the ace:dialog sample in showcase.

Thanks for you response.

I tried the commandButton. It fails if I don't put a type="button" attribute. If I do have the type="button attribute it stays open but then we have a set of radio buttons in the dialog that dynamically change the content in the dialog. After clicking on any one of the radio buttons, a post is made with the jsesssionid, the dialog disappears and we are back to the same problem. I saw this behavior yesterday when I tried using a straight <a> tag to allow access to the dialog.

The showcase works because the dialog that comes up is strictly client side. If you were to put any components in the dialog that required a post back while keeping the dialog open then I am pretty sure it would fail there too. Again all of this works find after we have reloaded the page. It is that pesky first load that messes it up. I have been down the path of urlrewriting but I don't think that is the problem or can fix it.

This is a problem that is somewhat independent of any component. We have a URL to a help page that was failing because the jsessionid was appended to it. We changed the tag to an <a> tag and it works. There needs to be a way to capture that first request from the page and filter out the jsessionid if it is going to be a problem. How to determine if it is going to be a problem is unclear to me.

I can replicate this in Chrome but it is important to have a new instance of the browser running each time.

Were there changes in the codebase that addressed this? We are using 3.1 pulled down in July.

Thanks

Please look at ICE-8388, where this issue is discussed some more. I'm thinking that a filter that does a temporary redirect back to the same url might solve this. Care must be taken to not infinitely redirect, especially when cookies are in fact disabled.

Mark,

Looked at ICE-8388. We came up with an alternative solution. We are using Weblogic and we put the following in weblogic.xml

<wls:session-descriptor>
<wls:cookie-name>AISSessionID</wls:cookie-name>
<wls:url-rewriting-enabled>false</wls:url-rewriting-enabled>
</wls:session-descriptor>

AIS is the name of our app. This solved the problem with the jsessionId issue. Now the jsessionid is not being appended the first time through. The dialogs now work properly as do any components that are activated first on the first rendered page. All our session interactions appear to be stable and complete. We are using a mixture of Application, Window and Request scopes throughout. We are using Tuckey for custom rewriting and there is no overlap with the above.

So far so good. Thank you for your responses. Definitely appreciated!