[
https://issues.apache.org/jira/browse/PDFBOX-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-699.
---------------------------------------
Resolution: Fixed
I've applied the patch with version 941832.
Thanks to Adam for the contribution
> 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
>
> Attachments: PDFBOX-699_fixed.patch
>
>
> 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.
