Hello, > Two possabilities occure to me: > 1) js.jar isn't in the class path for the WebStart app > 2) Vincent fixed a bug relating to class path handling and > JavaScript that is only in CVS (so try using current CVS).
Thanks for suggestions, but it is a SecurityException which is being thrown, so eventually, I ended up signing our application.jar + all batik.jars and after struggling :-) for the last several hours I've finally got the result, that is "text/ecmascript message ..." is not thrown anymore. Even though I'm quite happy I've managed :-) to get over all the security hurdles, I'd prefer some other way of preventing that exception from being thrown. I think of 2 ways : 1. Comment out the source code so that the JavaScript engine is not initiated. It would be great though if the standard Batik code could load the JavaScript engine when required only. 2. The SecurityException exception which is thrown doesn' crush our code, so I was thinking of just trying to call JSvgComponent.setDocumentStatus() from withing a separate ThreadGroup which overrides ThreadGroup.uncaughtException() Any comments will be appreciated, Cheers Sergey Beryozkin ----- Original Message ----- From: "Thomas E Deweese" <[EMAIL PROTECTED]> To: "Batik Users" <[EMAIL PROTECTED]> Sent: Wednesday, February 12, 2003 2:15 PM Subject: RE: text/ecmascript message > >>>>> "SB" == Siarhei Biarozkin <[EMAIL PROTECTED]> writes: > > SB> When I'm running our application from Java WebStart, the exception > SB> is thrown : java.lang.Exception : Unknown language : > SB> text/ecmascript at org.apache.batik.bridge.Base > SB> ScriptingEnvironment.dispatchSVGLoadEvent()... > > Two possabilities occure to me: > 1) js.jar isn't in the class path for the WebStart app > 2) Vincent fixed a bug relating to class path handling and > JavaScript that is only in CVS (so try using current CVS). > > Of the two I'm leaning towards #1, as #2 usually manifests > differently, as I recall). > > SB> This happens only if > SB> JSVGDocument.setDocumentState(ALWAYS_DYNAMIC). The reason we're > SB> calling this method is not because we're using scripting, but to > SB> enable an immediate update of the paint area, as Thomas pointed > SB> out. > > Part of the problem here is that a dyanmic SVG viewer _must_ > support ecma script, so I think it's hard-wired into Batik. I suspect > that it would not be too difficult to only bring up the JavaScript > engine if text/ecmascript script elements are encountered but isn't > done right now. > > SB> I remember seeing few days ago the recommendation to add > SB> <security> <all-permissions/> </security> to avoid some > SB> text/ecmascript-related problems. However, this requires an > SB> application jar be signed. > > SB> Is there any other way to prevent the above exception from being > SB> thrown, as we're not using scripts in the first place. Also, is > SB> there any way to specify that even if we are in an ALWAYS_DYNAMIC > SB> state, we don't need scripting support be loaded ? > > SB> On the performance issue : 256MB heap really made a difference, so > SB> we're a quite happy now as far as the initial display time is > SB> concerned > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
