Re: PDFBox*.tmp files not deleted by PDFParser
Hi, Thanks, I'll research this. I think you have a good argument, I just looked at PDDocument and there pdfSource is kept. Tilman Am 25.05.2016 um 12:11 schrieb Damien Butaye: Hello Tilman, For your information I found a workaround to avoid the problem of tmp file deletion. In the SignatureOptions object, I modified the method *public void setVisualSignature(InputStream is) *with the following content : RandomAccessBufferedFileInputStream tmp=new RandomAccessBufferedFileInputStream(is); --> NEW LINE PDFParser parser = new PDFParser(tmp); --> NEW LINE parser.parse(); visualSignature = parser.getDocument(); tmp.close(); --> NEW LINE Tmp files are well deleted and all unit tests passed without error on the pdfbox maven project. If you think it's not a good solution, don't hesitate to tell me. Thank you. 2016-05-25 10:01 GMT+02:00 Damien Butaye: Hello Tilman, Yes I did it. I verified in debug mode and this method (close() on SignatureOption) is well reached but the close() method of the object "RandomAccessBufferedFileInputStream" is never called, so the tmp file is never deleted. The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of the COSParser but this method is not called. It seems this method is called only in case of "xref stream" (line 286 COSParser) , why not in other case -> xref (line 218 COSParser)? Damien. 2016-05-24 20:10 GMT+02:00 Tilman Hausherr : did you close the options object? Tilman Am 24.05.2016 um 15:51 schrieb Damien Butaye: Dear all, I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp directory (RehHat server). This file is not deleted after completion. After some checks, it seems that the object responsible of the file creation is "RandomAccessBufferedFileInputStream(InputStream is)". This object is used by the PDFParser object which doesn't close the stream after completion. The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding the following line (see https://issues.apache.org/jira/browse/PDFBOX-2723) in the COSParser : xrefStream.close(); // <--- *** NEW LINE *** But, in debug mode, I saw this line is never reached so the stream is not closed and the tmp file is not deleted. Has anybody a workaround to handle this ? Thanks for your help! - To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org - To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
Re: PDFBox*.tmp files not deleted by PDFParser
Hello Tilman, For your information I found a workaround to avoid the problem of tmp file deletion. In the SignatureOptions object, I modified the method *public void setVisualSignature(InputStream is) *with the following content : RandomAccessBufferedFileInputStream tmp=new RandomAccessBufferedFileInputStream(is); --> NEW LINE PDFParser parser = new PDFParser(tmp); --> NEW LINE parser.parse(); visualSignature = parser.getDocument(); tmp.close(); --> NEW LINE Tmp files are well deleted and all unit tests passed without error on the pdfbox maven project. If you think it's not a good solution, don't hesitate to tell me. Thank you. 2016-05-25 10:01 GMT+02:00 Damien Butaye: > Hello Tilman, > > Yes I did it. I verified in debug mode and this method (close() on > SignatureOption) is well reached but the close() method of the object > "RandomAccessBufferedFileInputStream" is never called, so the tmp file is > never deleted. > The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of > the COSParser but this method is not called. It seems this method is called > only in case of "xref stream" (line 286 COSParser) , why not in other case > -> xref (line 218 COSParser)? > > Damien. > > 2016-05-24 20:10 GMT+02:00 Tilman Hausherr : > >> did you close the options object? >> >> Tilman >> >> >> Am 24.05.2016 um 15:51 schrieb Damien Butaye: >> >>> Dear all, >>> >>>I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the >>> process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp >>> directory (RehHat server). This file is not deleted after completion. >>> After some checks, it seems that the object responsible of the file >>> creation is "RandomAccessBufferedFileInputStream(InputStream is)". This >>> object is used by the PDFParser object which doesn't close the stream >>> after >>> completion. >>> >>> The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding >>> the >>> following line (see https://issues.apache.org/jira/browse/PDFBOX-2723) >>> in >>> the COSParser : >>> >>> xrefStream.close(); // <--- *** NEW LINE *** >>> >>> But, in debug mode, I saw this line is never reached so the stream is not >>> closed and the tmp file is not deleted. Has anybody a workaround to >>> handle >>> this ? >>> Thanks for your help! >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org >> For additional commands, e-mail: users-h...@pdfbox.apache.org >> >> >
Re: PDFBox*.tmp files not deleted by PDFParser
> Damien Butayehat am 25. Mai 2016 um 10:01 > geschrieben: > > > Hello Tilman, > > Yes I did it. I verified in debug mode and this method (close() on > SignatureOption) is well reached but the close() method of the object > "RandomAccessBufferedFileInputStream" is never called, so the tmp file is > never deleted. The RandomAccessBufferedFileInputStream is used for the whole document and for the SignatureOptions. You already confirmed that you close the latter one. What about the document itself, did you close it as well? > The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of the > COSParser but this method is not called. It seems this method is called > only in case of "xref stream" (line 286 COSParser) , why not in other case > -> xref (line 218 COSParser)? Neither a xrefstream nor a xref table uses its own RandomAccessBufferedFileInputStream, so that this question doesn't seem to be related to your problem. BR Andreas > Damien. > > 2016-05-24 20:10 GMT+02:00 Tilman Hausherr : > > > did you close the options object? > > > > Tilman > > > > > > Am 24.05.2016 um 15:51 schrieb Damien Butaye: > > > >> Dear all, > >> > >>I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the > >> process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp > >> directory (RehHat server). This file is not deleted after completion. > >> After some checks, it seems that the object responsible of the file > >> creation is "RandomAccessBufferedFileInputStream(InputStream is)". This > >> object is used by the PDFParser object which doesn't close the stream > >> after > >> completion. > >> > >> The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding > >> the > >> following line (see https://issues.apache.org/jira/browse/PDFBOX-2723) in > >> the COSParser : > >> > >> xrefStream.close(); // <--- *** NEW LINE *** > >> > >> But, in debug mode, I saw this line is never reached so the stream is not > >> closed and the tmp file is not deleted. Has anybody a workaround to handle > >> this ? > >> Thanks for your help! > >> > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > > For additional commands, e-mail: users-h...@pdfbox.apache.org > > > > - To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
Re: PDFBox*.tmp files not deleted by PDFParser
Hello Tilman, Yes I did it. I verified in debug mode and this method (close() on SignatureOption) is well reached but the close() method of the object "RandomAccessBufferedFileInputStream" is never called, so the tmp file is never deleted. The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of the COSParser but this method is not called. It seems this method is called only in case of "xref stream" (line 286 COSParser) , why not in other case -> xref (line 218 COSParser)? Damien. 2016-05-24 20:10 GMT+02:00 Tilman Hausherr: > did you close the options object? > > Tilman > > > Am 24.05.2016 um 15:51 schrieb Damien Butaye: > >> Dear all, >> >>I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the >> process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp >> directory (RehHat server). This file is not deleted after completion. >> After some checks, it seems that the object responsible of the file >> creation is "RandomAccessBufferedFileInputStream(InputStream is)". This >> object is used by the PDFParser object which doesn't close the stream >> after >> completion. >> >> The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding >> the >> following line (see https://issues.apache.org/jira/browse/PDFBOX-2723) in >> the COSParser : >> >> xrefStream.close(); // <--- *** NEW LINE *** >> >> But, in debug mode, I saw this line is never reached so the stream is not >> closed and the tmp file is not deleted. Has anybody a workaround to handle >> this ? >> Thanks for your help! >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: users-h...@pdfbox.apache.org > >
Re: PDFBox*.tmp files not deleted by PDFParser
did you close the options object? Tilman Am 24.05.2016 um 15:51 schrieb Damien Butaye: Dear all, I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp directory (RehHat server). This file is not deleted after completion. After some checks, it seems that the object responsible of the file creation is "RandomAccessBufferedFileInputStream(InputStream is)". This object is used by the PDFParser object which doesn't close the stream after completion. The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding the following line (see https://issues.apache.org/jira/browse/PDFBOX-2723) in the COSParser : xrefStream.close(); // <--- *** NEW LINE *** But, in debug mode, I saw this line is never reached so the stream is not closed and the tmp file is not deleted. Has anybody a workaround to handle this ? Thanks for your help! - To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
PDFBox*.tmp files not deleted by PDFParser
Dear all, I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp directory (RehHat server). This file is not deleted after completion. After some checks, it seems that the object responsible of the file creation is "RandomAccessBufferedFileInputStream(InputStream is)". This object is used by the PDFParser object which doesn't close the stream after completion. The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding the following line (see https://issues.apache.org/jira/browse/PDFBOX-2723) in the COSParser : xrefStream.close(); // <--- *** NEW LINE *** But, in debug mode, I saw this line is never reached so the stream is not closed and the tmp file is not deleted. Has anybody a workaround to handle this ? Thanks for your help!