xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John C. Turnbull" <ozem...@ozemail.com.au>
Subject RE: FW: Strange applet delay revisited
Date Tue, 20 Jan 2009 19:18:10 GMT
Hi Thomas,


I suspect that existing scripts may be broken by this change and that is
probably unacceptable but I am happy to make the change locally as my
scripts are still under development.


With the other alternative of importing the classes individually, do you
know exactly which classes will need to be imported?  I would like to try
out the performance of implementing this option.






From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com] 
Sent: Tuesday, 20 January 2009 22:37
To: batik-users@xmlgraphics.apache.org
Cc: batik-users@xmlgraphics.apache.org
Subject: RE: FW: Strange applet delay revisited


Hi John,

"John C. Turnbull" <ozemale@ozemail.com.au> 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
> my Batik applications either so I would vote to have it included in the
> 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
> 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:helder.magalhaes@gmail.com]
> > Sent: Saturday, 17 January 2009 02:45
> > To: batik-users@xmlgraphics.apache.org
> > 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] 

View raw message