>> So for some reason, the script takes longer to evaluate when the >> applet is served up from GlassFish than it does when it's run from >> the local file system. Why would this be? > > This is a feature of Rhino (and the way we use it) see the two > message threads for more information:
Thomas is right (as usual! :-) ), this is caused by Rhino. What happens is that Rhino tries to find (server-side) class files for each global ECMAScript variable you use. If you analyze the Web server logs you should be able to see lots of files being tentatively retrieved (most certainly resulting in 404 HTTP codes). Declaring the variables before using them seems to help a bit, although I found that still a few requests annoyingly seemed to still be issued to the server. I've made a quick hack on my working copy (attached), but didn't have the chance to evaluate the impact on Batik itself in order to share with the community and/or polish it for a bug report attachment. According to the comments, it sounds like this would seriously hurt Batik, but I didn't notice anything unusual... Could this change be reviewed...? I'd suggest that, if there is no intention of disabling this Rhino feature, it surely would be cool to allow a configuration enabling/disabling it, as applets usually don't make use of this somehow excentric feature and it sounds that it would still be possible (though explicit "importPackage" calls). Does this sound reasonable and worth a follow-up? Hope this helps, Helder
disable-rhino-class-loader.patch
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
