Hi John, "John C. Turnbull" <[email protected]> wrote on 01/18/2009 10:01:10 PM:
> 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. I think there will be issues since the interfaces from the DOM packages won't be available in the global ECMAScript namespace. This is obviously not as important in ECMAScript as other languages (where you need to cast etc). But I suspect that some valid ECMAScript code will fail without the imports. Before this goes into SVN someone needs to carefully analyze the actual ECMAScript implications. The other alternative as Cameron suggested would be to replace the package imports with the needed individual class imports. > > -----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 > > [attachment "PGP.sig" deleted by Thomas E. DeWeese/449433/EKC]
