Helder, I have applied your patch to my local Batik and it has resolved the delays with applet scripting so thanks for that. And, I see no negative effect on my Batik applications either so I would vote to have it included in the SVN source unless there are problems I just haven't encountered yet. I don't mind manually importing any required Java classes/packages in my scripts and if this is the only drawback then I think you have a winner.
Cheers, John > -----Original Message----- > From: Helder Magalhães [mailto:[email protected]] > Sent: Saturday, 17 January 2009 02:45 > To: [email protected] > Subject: Re: FW: Strange applet delay revisited > > >> 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
PGP.sig
Description: PGP signature
