Hello, I'll answer between lines, and correct a mistake of my first email in the process:
2012/3/9 Hussein Shafie <[email protected]>: > On 03/09/2012 08:19 PM, Fabián Mandelbaum wrote: >> >> Thanks a lot for your prompt and accurate (as usual) answer. I guess >> we'll have to test and deploy XXE 5.2 applet when it's ready then... >> >> >>> [email protected] wrote: >>> We have managed to reproduce the behavior you describe. It is caused by >>> Oracle/Sun implementation of an HTTP URL which by default caches >>> previously >>> loaded files. >>> >>> We have partially implemented a fix for this bug. A more complete fix >>> will >>> be found in XXE v5.2, which should be released next week. >>> > > > After investigating more about this, we have found that: > > * This problem occurs when XXE is deployed as an applet and this, whatever > the browser or the Java version being used. > > * This problem also occurs when XXE is deployed using Java Web Start. > > * There is no way to reproduce this problem using the XXE desktop > application. > Indeed, the notice that we had the same problem running XXE standalone (desktop app) was a mistake on my original email. The behaviour we've noticed is consistent with this, XXE desktop application does not present this bug. > * This problem seems to be caused by a bug in the implementation of Java's > HTTP URL: > > Even if the file downloaded using Java's HTTP URL is cached by default, Java > should be able to detect (by querying the HTTP server) that the file has > been modified since then, which implies that the corresponding entry in > Java's cache is dirty. > > We'll add a workaround for this Java bug in XXE v5.2. > I had some crazy ideas about using the ETag HTTP standard header (and thus WebDAV too) to mark the file as being different, but I guess it won't help much working around a buggy Java network cache class... Thanks again. -- Fabián Mandelbaum IS Engineer -- XMLmind XML Editor Support List [email protected] http://www.xmlmind.com/mailman/listinfo/xmleditor-support
