[jira] [Commented] (PDFBOX-2566) Remove logging from operator classes
[ https://issues.apache.org/jira/browse/PDFBOX-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14498611#comment-14498611 ] ASF subversion and git services commented on PDFBOX-2566: - Commit 1674143 from [~tilman] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1674143 ] PDFBOX-2566: delete wrong operand count on more operators Remove logging from operator classes Key: PDFBOX-2566 URL: https://issues.apache.org/jira/browse/PDFBOX-2566 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 2.0.0 Reporter: John Hewson Assignee: John Hewson Priority: Minor Fix For: 2.0.0 I've been trying to get better control over the logging that occurs in the operator classes, but it's not easy to do so. Ideally all logging could pass through PDFStreamEngine so that subclasses can more easily filter what they want. By using exceptions instead of logging for error cases, we allow more fine-grained management of exceptions. For example, in my own code I wish for a missing XObject to be a terminal failure, but it currently just results in a log message, and I have to implement a custom DrawObject operator and copy paste over most of the code in order to catch this exception rather than logging it. I'm therefore going to move what little logging there is in the Operator classes over to PDFStreamEngine, and to throw custom exceptions (e.g. MissingResourceException) rather than writing silently to the log. The default implementation of processOperator in PDFStreamEngine will then catch these custom exceptions and simply write them to the log - keeping the current PDFBox behaviour unchanged. Only now consumers of PDFStreamEngine can override processOperator and do their own exception handling, e.g. I can choose to propagate MissingResourceException exception instead of logging it. This might be useful for Preflight too, as it often wants to throw errors where we would otherwise skip the offending object and just keep processing. Also it probably means that there will no longer be a need for to Preflight implement its own operators in those cases where it was done just to get stricter error handing. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2566) Remove logging from operator classes
[ https://issues.apache.org/jira/browse/PDFBOX-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14248557#comment-14248557 ] ASF subversion and git services commented on PDFBOX-2566: - Commit 1646026 from [~tilman] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1646026 ] PDFBOX-2566: remove unused imports Remove logging from operator classes Key: PDFBOX-2566 URL: https://issues.apache.org/jira/browse/PDFBOX-2566 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 2.0.0 Reporter: John Hewson Assignee: John Hewson Priority: Minor Fix For: 2.0.0 I've been trying to get better control over the logging that occurs in the operator classes, but it's not easy to do so. Ideally all logging could pass through PDFStreamEngine so that subclasses can more easily filter what they want. By using exceptions instead of logging for error cases, we allow more fine-grained management of exceptions. For example, in my own code I wish for a missing XObject to be a terminal failure, but it currently just results in a log message, and I have to implement a custom DrawObject operator and copy paste over most of the code in order to catch this exception rather than logging it. I'm therefore going to move what little logging there is in the Operator classes over to PDFStreamEngine, and to throw custom exceptions (e.g. MissingResourceException) rather than writing silently to the log. The default implementation of processOperator in PDFStreamEngine will then catch these custom exceptions and simply write them to the log - keeping the current PDFBox behaviour unchanged. Only now consumers of PDFStreamEngine can override processOperator and do their own exception handling, e.g. I can choose to propagate MissingResourceException exception instead of logging it. This might be useful for Preflight too, as it often wants to throw errors where we would otherwise skip the offending object and just keep processing. Also it probably means that there will no longer be a need for to Preflight implement its own operators in those cases where it was done just to get stricter error handing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2566) Remove logging from operator classes
[ https://issues.apache.org/jira/browse/PDFBOX-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14248782#comment-14248782 ] ASF subversion and git services commented on PDFBOX-2566: - Commit 1646060 from [~jahewson] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1646060 ] PDFBOX-2566: Throw MissingOperandException for missing operands Remove logging from operator classes Key: PDFBOX-2566 URL: https://issues.apache.org/jira/browse/PDFBOX-2566 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 2.0.0 Reporter: John Hewson Assignee: John Hewson Priority: Minor Fix For: 2.0.0 I've been trying to get better control over the logging that occurs in the operator classes, but it's not easy to do so. Ideally all logging could pass through PDFStreamEngine so that subclasses can more easily filter what they want. By using exceptions instead of logging for error cases, we allow more fine-grained management of exceptions. For example, in my own code I wish for a missing XObject to be a terminal failure, but it currently just results in a log message, and I have to implement a custom DrawObject operator and copy paste over most of the code in order to catch this exception rather than logging it. I'm therefore going to move what little logging there is in the Operator classes over to PDFStreamEngine, and to throw custom exceptions (e.g. MissingResourceException) rather than writing silently to the log. The default implementation of processOperator in PDFStreamEngine will then catch these custom exceptions and simply write them to the log - keeping the current PDFBox behaviour unchanged. Only now consumers of PDFStreamEngine can override processOperator and do their own exception handling, e.g. I can choose to propagate MissingResourceException exception instead of logging it. This might be useful for Preflight too, as it often wants to throw errors where we would otherwise skip the offending object and just keep processing. Also it probably means that there will no longer be a need for to Preflight implement its own operators in those cases where it was done just to get stricter error handing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2566) Remove logging from operator classes
[ https://issues.apache.org/jira/browse/PDFBOX-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245749#comment-14245749 ] ASF subversion and git services commented on PDFBOX-2566: - Commit 1645372 from [~jahewson] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1645372 ] PDFBOX-2566: Move logging from Operator classes to PDFStreamEngine Remove logging from operator classes Key: PDFBOX-2566 URL: https://issues.apache.org/jira/browse/PDFBOX-2566 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 2.0.0 Reporter: John Hewson Priority: Minor Fix For: 2.0.0 I've been trying to get better control over the logging that occurs in the operator classes, but it's not easy to do so. Ideally all logging could pass through PDFStreamEngine so that subclasses can more easily filter what they want. By using exceptions instead of logging for error cases, we allow more fine-grained management of exceptions. For example, in my own code I wish for a missing XObject to be a terminal failure, but it currently just results in a log message, and I have to implement a custom DrawObject operator and copy paste over most of the code in order to catch this exception rather than logging it. I'm therefore going to move what little logging there is in the Operator classes over to PDFStreamEngine, and to throw custom exceptions (e.g. MissingResourceException) rather than writing silently to the log. The default implementation of processOperator in PDFStreamEngine will then catch these custom exceptions and simply write them to the log - keeping the current PDFBox behaviour unchanged. Only now consumers of PDFStreamEngine can override processOperator and do their own exception handling, e.g. I can choose to propagate MissingResourceException exception instead of logging it. This might be useful for Preflight too, as it often wants to throw errors where we would otherwise skip the offending object and just keep processing. Also it probably means that there will no longer a need for to Preflight implement its own operators in those cases where it was done just to get stricter error handing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
