Hello, Thank you for your quick fix. My Question is now how to get to the new source? Should i take it from the builds ? And when yes then is that the correct one batik-svn-09-07-13.zip <http://people.apache.org/builds/xml-batik/batik-svn-09-07-13.zip> ? Dipl.-Ing. (FH) Michael Kerschbaum Entwicklung
PKE Electronics AG Computerstraße 6 A-1100 Wien Tel: +43 (0)50150 1210 Fax: +43 (0)50150 1042 Mobil: +43 (0)664 80470 1210 [email protected] http://www.pke.at <http://www.pke.at/> 1979 - 2009 *** 30 Jahre PKE *** Aktiengesellschaft mit dem Sitz in Wien Firmenbuchnummer 103264i HG Wien, DVR 0159701 Johann Helf - Vorsitzender des Vorstandes Bruno Faustka - Mitglied des Vorstandes Christian Prelz - Vorsitzender des Aufsichtsrates ________________________________ Von: [email protected] [mailto:[email protected]] Gesendet: Montag, 13. Juli 2009 12:50 An: [email protected] Cc: [email protected] Betreff: Re: WG: Images in Batik kept open... Hi Michael, "Kerschbaum Michael " <[email protected]> wrote on 07/08/2009 05:28:56 AM: > Thomas you said its not a good idea to release the ProtectedStream > reference. This is clear, because of the ImageTagRegistry#readUrl > when sre.handleStream(is, purl, needRawData); is called. Then the > PNGRegistryEntry is used, where a Thread creates the Image. But what > about calling is.close(); => I would call in ProtectedStream#close > the release method ? Is there any reason of doing nothing in the > close method of ProtectedStream ? I mean otherwise the is must be > casted to ProtectedStream and calls release. So I've committed a fix for the basic problem. I tested and when appropriate I believe all of the streams are closed now. There are two issues I was dealing with. First I didn't want to have to reopen image streams repeatedly (for SVG, for PNG, JPEG, GIF, TIFF, etc...). Second some image formats need to keep a reference to the stream (they read the data as needed instead of all up front). The first meant that the normal 'close' method can't really close the stream, the second meant that the higher level code can't call 'release' (because the lower level code might need the stream still). So the fix is to remember if the lower level has closed the stream, and to have the higher level code notify the stream when it is 'tied' to a particular codec. Then when both are true it can close the underlying stream for real. > Von: Kerschbaum Michael [mailto:[email protected]] > Gesendet: Mittwoch, 08. Juli 2009 10:25 > An: [email protected] > Betreff: Images in Batik kept open... > Hello, > > I have the problem, that when a svg has an image via xlink, this > image can't be deleteted or renamed, removed any more after the svg > was loaded. And the image is still locked after the svg document was > disposed. I have found a problem report for that ...svg:image - referred > images kept open?... but there was no solution posted. Is there a > solution or a workaround ? > > The Problem is, that my application views svgs with png images. The > svg's and png's stored on an samba share, and a nother application > updates them. This application is not able to put the png file to > the share ? Clean up the image and svg cache in batik didn't help. > > > mfg Michael > >
