Add support for InputStreams to PDFMergerUtility
------------------------------------------------
Key: PDFBOX-699
URL: https://issues.apache.org/jira/browse/PDFBOX-699
Project: PDFBox
Issue Type: Improvement
Components: Utilities
Reporter: Adam Nichols
Priority: Minor
Fix For: 1.2.0
Currently the PDFMergerUtility class is only set up to merge files, not
streams. I need to extend this to be able to handle both and I'm trying to
determine how best to do this so it can be contributed back in a manner which
won't disrupt others.
Currently there's a List<File> which holds all the source documents. I'd like
to convert this to a List<InputStream> but the problem arises in when
exceptions are thrown. The normal usage of this class would be something like
this:
PDFMergerUtility merger = new PDFMergerUtility();
merger.setDestinationFileName("output.pdf");
merger.addSource("file0.pdf");
File pdf1 = new Flie("file1.pdf");
merger.addSource(pdf1); // just demonstrating files work as well as filenames
merger.mergeDocuments();
mergeDocuments() is the only thing above which may throw an exception. If the
List were converted to hold InputStream object, we could just wrap the File
with a "new FileInputStream(sourceFile)" and "new FileInputStream(new
File(sourceFileName))". The problem is that may throw an exception if the file
can't be read for some reason. I don't really want to just log an error
(basically ignoring the problem, in terms of the path of code execution), but
I'm hesitant to change the API so addSource() throws an exception. Order
matters (i.e. merging file0 with file1 isn't the same as merging file1 with
file0), so it'd be difficult to have two lists (one for Files and one for
Streams). The other thing I thought it catching the Exception and throwing a
RuntimeException (which doesn't need to be declared in the API).
So I'm looking for some feedback from the community here. The cleanest
solution is to add "throws Exception" to the addSource() methods (they already
may throw a NullPointerException, but that's a RuntimeException...). Do you
think changing the API an option? If not, how would it be best to handle this?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
