Details
-
Bug
-
Status: Open
-
Resolution: Unresolved
-
1.6
-
None
-
None
-
Operating System: Linux
Platform: PC
Description
I have a Swing program that tries to load several SVG documents
using several JSVGCanvases at the same time. These images all
have within them some <image> tags that import the same other
external SVG documents.
Sample import:
<image x="2214.0" y="9.0" transform="scale(0.5)"
width="313.0" xlink:href="../images/logo1.svg"
height="163.0" preserveAspectRatio="xMaxYMax meet"/>
When loading these documents at the same time, it appears there is
some sort of race condition that causes the exception below from
all the images, and they all fail to load.
Note that the <image>'s URL references an SVG file, so I'm not
sure why Toolkit.createImage() is being used (as it appears) but
I don't understand the inner workings.
2006-07-11 19:31:56,991 [AWT-EventQueue-0] ERROR: BasicUserAgent Error:
org.apache.batik.bridge.BridgeException:
http://test1.example.com/maps/map1.svg.gz:-1
The URI "http://test1.example.com/imgs/../test/logo1.svg"
on element <image> can't be opened because:
JDK URL is corrupt or unsupported variant
at
org.apache.batik.swing.svg.JSVGComponent$BridgeUserAgent.getBrokenLinkDocument(Unknown
Source)
at org.apache.batik.swing.svg.JSVGComponent$26Query.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Notes:
- This only occurs when multiple JSVGCanvases are attempting to load and build
their documents at the same time. - This only occurs when the imported file is SVG. When I rasterize it to PNG and
import that instead, the problem goes away.
This seems like it must be a bug in Batik's document caching subsystem.