Correction to the description: "with the default distribution this doesn't change anything" is not accurate.
The WAR ships jbig2-imageio (a transitive dependency of Tika / PDFBox), which registers a read-only ImageIO reader for image/x-jbig2 (Tika maps *.jb2 to this media type). So today, a resize request (e.g. ?width=100) on a .jb2 attachment already goes through the decode / failed write / warning / no cache cycle described above.
All the other readers bundled by default (JDK, TwelveMonkeys imageio-jpeg, jai-imageio-core) have a matching writer, so JBIG2 is the only format whose behaviour changes with the proposed fix: such images are served directly, without decoding them.
Correction to the description: "with the default distribution this doesn't change anything" is not accurate.
The WAR ships {{jbig2-imageio}} (a transitive dependency of Tika / PDFBox), which registers a *read-only* ImageIO reader for {{image/x-jbig2}} (Tika maps {{*.jb2}} to this media type). So today, a resize request (e.g. {{{}?width=100{}}}) on a {{.jb2}} attachment already goes through the decode / failed write / warning / no cache cycle described above.
All the other readers bundled by default (JDK, TwelveMonkeys {{{}imageio-jpeg{}}}, {{{}jai-imageio-core{}}}) have a matching writer, so JBIG2 is the only format whose behaviour changes with the proposed fix: such images are served directly, without decoding them.
--- _Generated by [Claude Code|https://claude.ai/code]_
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
