[
https://issues.apache.org/jira/browse/FOP-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18080416#comment-18080416
]
Simon Steiner commented on FOP-3312:
------------------------------------
you could use a new fopfactory each time you render to avoid caches
> Image loading problems
> ----------------------
>
> Key: FOP-3312
> URL: https://issues.apache.org/jira/browse/FOP-3312
> Project: FOP
> Issue Type: Bug
> Components: image/unqualified
> Affects Versions: 2.11
> Environment: * OS: Microsoft Windows [Version 10.0.26100.32690]
> * Java: openjdk version "25.0.2" 2026-01-20 LTS
> OpenJDK Runtime Environment Temurin-25.0.2+10 (build 25.0.2+10-LTS)
> OpenJDK 64-Bit Server VM Temurin-25.0.2+10 (build 25.0.2+10-LTS, mixed mode,
> sharing)
> * Apache FOP 2.11
> Reporter: M.H.
> Priority: Major
>
> Hello, we use FOP since the pre versions before 0.95. In FOP-1587 we already
> had problems with "duplicate images" in PDFs because the ImageCache in FOP
> didn't support relative Paths correctly:
> <fo:external-graphic width="255mm" src="images/Logo1.svg"/>
> As FOPs internal cache used this relative path as an "ID". I don't know if
> current FOP Versions changed this, but our workaround was to clear the image
> cache before each new PDF rendering.
> Our custom resolver detects specific "...images/" and "...documents/" paths
> and changes those paths to the final (correct) location of such
> image/document files (because their location is at other fixed folder paths -
> not relative to FOPs current working directory):
> {code:java}
> // code placeholder
> public Resource getResource(final URI uri) throws IOException {
> Resource result = null;
> if (isFine) {
> LOGGER.info(getClass().getName()+".getResource("+uri+") ...");
> } if (uri != null) {
> //String scheme = uri.getScheme(); //e.g. "file"
> String part = uri.getSchemeSpecificPart(); if
> (part != null) {
> String fn = part.toLowerCase();
> //adjustment: replace Windows backslash to URI forward slash path separator.
> if (0 < fn.indexOf('\\')) { //path contains backslah?
> fn = fn.replace('\\', '/'); //replace backslash
> (Windows file separator) with forward slash (URI)
> if (isFine) {
>
> LOGGER.info(getClass().getName()+".getResource("+uri+") \\: "+uri+" => "+fn);
> }
> } //adjustment: add fixed parent
> directory to documents:
> if (fn.startsWith("documents/")) { //e.g. "documents/..."
> String fnn = dirCurrent + fn;
> if (isFine) {
>
> LOGGER.info(getClass().getName()+".getResource("+uri+") documents/: "+uri+"
> => "+fnn);
> }
> result = new Resource("", new FileInputStream(fnn));
> } //adjustment: add fixed parent
> directory to images:
> if (fn.startsWith("images/")) {
> String fnn = dirBase + '/' + fn;
> if (isFine) {
>
> LOGGER.info(getClass().getName()+".getResource("+uri+") images/: "+uri+" =>
> "+fnn);
> }
> result = new Resource("", new FileInputStream(fnn));
> } else if (fn.contains("/images/")) {
> int i = fn.indexOf("/images/");
> if (0 < i) {
> String fnn = dirBase + fn.substring(i);
> if (isFine) {
>
> LOGGER.info(getClass().getName()+".getResource("+uri+") /images/: "+uri+" =>
> "+fnn);
> }
> result = new Resource("", new FileInputStream(fnn));
> }
> }
> }//else: part unavailable if (result == null) {
> result = defaultResolver.getResource(uri);
> }
> }
> return result;
> }//getResource() {code}
>
> This worked flawlessly for many years inkl. FOP 2.7. Then our runtime
> environment changed to a faster TrueNAS system with fast NVMe storage. Since
> then the problems occured that sometimes the FOP renderings didn't find any
> images anymore! Our custom EventListener triggers "image not found" events
> every now and then. (Reprdoducing the same document again works - so it's a
> timing/race condition)
> We upgraded to FOP 2.11 but without any improvement. We made a lot of "work
> around" changes in our custom resolver - without any improvement.
> So, after many years of image problems with FOP (see bug FOP-1587) we are
> here with "FOP image problems" again! We have a lot of XSLs with such
> relative paths for images/documents and our custom resolver handled the
> change of the paths. And this still works on all our other non-TrueNas
> Systems. So, somehow the faster system probably revealed a sleeping race
> condition or something similar. And alle things we tried in the custom
> resolver doesn't help - we get "image not found" on this system every day.
> Is there some API in FOP that can help resolving this issue? Is there a way
> to tell FOP to somehow "retry" loading an image if there is a problem? As I
> read so far, there is no way to disable this FOP image cache completely or
> have mor control over it?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
