[
https://issues.apache.org/jira/browse/PDFBOX-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964936#comment-16964936
]
Andreas Lehmkühler edited comment on PDFBOX-4671 at 11/11/19 4:34 PM:
----------------------------------------------------------------------
As I'm following this issue (through
[https://github.com/haraldk/TwelveMonkeys/issues/503] I might as well throw in
my two cents.. ;)
# I would argue that an {{ImageReader}} implementation should not be bothered
by logging at all. This logging information is really only useful for debugging
by the developers of the library, and not users.
If you need to inform the user of possible problems while decoding, this can
be handled through the {{IIOReadWarningListener}} interface, and client code
can decide whether they choose to log, display or simply ignore such problems.
Unrecoverable errors in decoding should be handled though exceptions as normal
(typically an {{IIOException}} subclass).
# Caching of bitmap data (which is the only thing the cache is used for in the
current code) is probably better kept out of the {{ImageReader}}, and instead
in the client code that uses it. This allows for a more general caching of
bitmap data, independent of the reader/format implementation.
Some deeper analysis of the logging...
* There are 4 usages of {{Log.debug }}
* There are 36 usages of {{Log.info}}. Both of these seems mostly debugging
like info for the reader developer, and could probably be mostly removed (I
only looked at ten or so random instances, YMMV). A proper debugger setup will
allow you to inspect these values while developing/running test cases anyway.
* There is a single usage of {{Log.warn}}. I believe this could probably be
warning for the listener instead.
* There are two usages of {{Log.error}}. Could probably be warning for the
listener instead (unless it's really an error, and an exception should be
thrown instead),
* None of the above use the overload with {{Throwable}}. There are also no
usages of {{Log.fatal}} whatsoever (probably a good thing).
* There's an extra field in the reader enabling/disabling debug,
{{JBIG2ImageReader.DEBUG}}. It's usually not used with a logger but instead
prints to {{System.out}} (!).
But it's sometimes used in combination, and allows for cluttered code like
this:
{{if (JBIG2ImageReader.DEBUG)}}
{
{{ if (log.isDebugEnabled())}}
{{ {}}
{{ log.debug(segment.toString());}}
}
{{}}}
Best regards,
--
Harald K
was (Author: haraldk76):
As I'm following this issue (through
[https://github.com/haraldk/TwelveMonkeys/issues/503)] I might as well throw in
my two cents.. ;)
# I would argue that an {{ImageReader}} implementation should not be bothered
by logging at all. This logging information is really only useful for debugging
by the developers of the library, and not users.
If you need to inform the user of possible problems while decoding, this can
be handled through the {{IIOReadWarningListener}} interface, and client code
can decide whether they choose to log, display or simply ignore such problems.
Unrecoverable errors in decoding should be handled though exceptions as normal
(typically an {{IIOException}} subclass).
# Caching of bitmap data (which is the only thing the cache is used for in the
current code) is probably better kept out of the {{ImageReader}}, and instead
in the client code that uses it. This allows for a more general caching of
bitmap data, independent of the reader/format implementation.
Some deeper analysis of the logging...
* There are 4 usages of {{Log.debug }}
* There are 36 usages of {{Log.info}}. Both of these seems mostly debugging
like info for the reader developer, and could probably be mostly removed (I
only looked at ten or so random instances, YMMV). A proper debugger setup will
allow you to inspect these values while developing/running test cases anyway.
* There is a single usage of {{Log.warn}}. I believe this could probably be
warning for the listener instead.
* There are two usages of {{Log.error}}. Could probably be warning for the
listener instead (unless it's really an error, and an exception should be
thrown instead),
* None of the above use the overload with {{Throwable}}. There are also no
usages of {{Log.fatal}} whatsoever (probably a good thing).
* There's an extra field in the reader enabling/disabling debug,
{{JBIG2ImageReader.DEBUG}}. It's usually not used with a logger but instead
prints to {{System.out}} (!).
But it's sometimes used in combination, and allows for cluttered code like
this:
{{if (JBIG2ImageReader.DEBUG)}}
{
{{ if (log.isDebugEnabled())}}
{{ {}}
{{ log.debug(segment.toString());}}
}
{{}}}
Best regards,
--
Harald K
> NoClassDefFoundError: Could not initialize class
> org.apache.pdfbox.jbig2.JBIG2ImageReader
> -----------------------------------------------------------------------------------------
>
> Key: PDFBOX-4671
> URL: https://issues.apache.org/jira/browse/PDFBOX-4671
> Project: PDFBox
> Issue Type: Bug
> Components: JBIG2
> Affects Versions: 3.0.2 JBIG2
> Reporter: Luis Panadero Guardeño
> Assignee: Joerg O. Henne
> Priority: Major
> Attachments: jbig2 servlet failcase.tar.gz
>
>
> JBIG2 ImageIO plugin sometimes does a NoClassDefFoundError
> I'm using TwelveMonkeys IIOProviderContextListener to fix the problem of
> ImageIO with servlets, and additionally doing a
> {{ImageIO}}.{{scanForPlugins}}(). But this keeps happening randomly. Any idea
> where could be the problem ?
> This is happening with Tomcat 7 running over Oracle Java 8 (latest version)
>
> {code:java}
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.pdfbox.jbig2.JBIG2ImageReader
> at
> org.apache.pdfbox.jbig2.JBIG2ImageReaderSpi.createReaderInstance(JBIG2ImageReaderSpi.java:117)
> at
> javax.imageio.spi.ImageReaderSpi.createReaderInstance(ImageReaderSpi.java:320)
> at javax.imageio.ImageIO$ImageReaderIterator.next(ImageIO.java:529)
> at javax.imageio.ImageIO$ImageReaderIterator.next(ImageIO.java:513)
> at org.apache.pdfbox.filter.Filter.findImageReader(Filter.java:155)
> at org.apache.pdfbox.filter.JBIG2Filter.decode(JBIG2Filter.java:67)
> at org.apache.pdfbox.cos.COSInputStream.create(COSInputStream.java:84)
> at org.apache.pdfbox.cos.COSStream.createInputStream(COSStream.java:175)
> at
> org.apache.pdfbox.pdmodel.common.PDStream.createInputStream(PDStream.java:241)
> at
> org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.createInputStream(PDImageXObject.java:735)
> at
> org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.from1Bit(SampledImageReader.java:253)
> at
> org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.getRGBImage(SampledImageReader.java:212)
> at
> org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.getImage(PDImageXObject.java:444)
> at
> org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.getImage(PDImageXObject.java:425)
> at org.apache.pdfbox.rendering.PageDrawer.drawImage(PageDrawer.java:1100)
> at
> org.apache.pdfbox.contentstream.operator.graphics.DrawObject.process(DrawObject.java:63)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:869)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:505)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:479)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:152)
> at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:263)
> at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:321)
> at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:243)
> at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:203)
> at
> com.digibis.digiimage.pdf.pdfbox.PdfBoxPdfProcessor.getImageFromDocumentPage(PdfBoxPdfProcessor.java:105){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
