is setting me javascript errors when running the page that contains the component ace: fileentry IE8 browser

anyone can help me

thanks

For this issue, the work-around is to not upload immedaitely from the first page that the user accesses in their session. Make the user do a postback first, such as to login, or to make the ace:fileEntry show up in an ace:dialog after they click a button.

I think that the framework solution to the Dom difference cascade is just that when a page does a GET and it renders the jsessionid into the urls, that any postback should continue adding the jsessionid. When another GET happens then it would not add the jsessionid.

Don't allow the user to upload immediately from the first page that the user accesses in their session. Make the user do a postback first, such as to login, or to make the ace:fileEntry show up in an ace:dialog after they click a button.

We have three ace:dialogs accessible from our first page. One is activated by a ice:commandLink and the others by a ace:pushButton, each with a simple onclick="dialog.show()". Standard along the the lines of how it is done in the showcase. Upon, first entry into the page, if the user clicks on anyone of them first the jsessionid is appended to the post. The dialog flashes and disappears. Refreshing the browser then allows all the dialogs to work properly. The dialogs have the same problem as the ace:fileEntry. Can we process the post differently for the one with the jsessionId? That wasn't suggested above so I am assuming that isn't a possible solution.

Not allowing the user to access these kinds of components is very restrictive. In our case we have SSO so the user is already authenticated when they hit the site. Thought about putting a splash screen with a forward up but that seems a bit contrived just to cover the issue.

We are using Weblogic 12c. We understand that by default 12c appends the jsessionid for the exact reasons described in the description of this issue.

Are there any other possibilities you can think of?

Thanks

I can replicate the above in IE8 and Chrome.

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!