3

I am upgrading to ColdFusion 2018. iText routines that I use to convert and rotate PDFs, the pdfReader puts locks on the file that do not release when the page is done.

I have tried adding a close() method to my code. (It was not needed on the pdfReader in Release 11.)

<cfscript>

reader = createObject("java", "com.lowagie.text.pdf.PdfReader").init( "test.pdf" );

reader.close();

inStream = createObject("java", "java.io.FileReader").init("test2.pdf");

inStream.close();

</cfscript>

I would expect to be able to rename or delete both files when the supplied script is ran, but only the inStream file (test2.pdf) can be. The reader file (test.pdf) is locked by the system.

Miguel-F
  • 13,450
  • 6
  • 38
  • 63
Michael Miller
  • 61
  • 3
  • I get the same result. Some internal (CF) voodoo must be holding onto a reference. To work around it, pass in an inputstream (or RandomAccessFileOrArray) instead of file name. When finished with the reader, close() the stream. That works. *was not needed on the pdfReader in Release 11* Still best to close things explicitly, even if not technically needed. – SOS May 29 '19 at 20:31
  • 2
    Which version of iText is that anyway? It must at least be 10 years old, probably older... – Amedee Van Gasse May 29 '19 at 20:47
  • Thank you! I think that will solve my issue. – Michael Miller May 30 '19 at 15:34
  • What do you mean by "convert"? What kind of source are you starting with? – Shawn May 30 '19 at 18:00

2 Answers2

2

Using the suggestions above, I think the following solution will work.

<cfscript>

    fkeys = createObject("java", "java.io.FileInputStream");
    lKeyStoreFileStream = createObject("java", "java.io.BufferedInputStream").init(fkeys.init("test.pdf"));    

    reader = createObject("java", "com.lowagie.text.pdf.PdfReader").init( lKeyStoreFileStream );

    lKeyStoreFileStream.close();
    fkeys.close();

    reader.close();

</cfscript>
SOS
  • 6,430
  • 2
  • 11
  • 29
Michael Miller
  • 61
  • 3
0

Rather than using an older Java plugin, just use the native cfpdf. 

<cfpdf action="transform" source="myPDF.pdf" rotation="90" name="outPDF">

There is a ton of other functionality available to this tag. https://cfdocs.org/cfpdf

https://cffiddle.org/app/file?filepath=eca41ba2-22f2-41f2-a205-0c2d3aafe91c/ca3873c8-4d4b-4cfc-8e64-6c4ceb825717/9861993d-7db3-43ee-882f-681a1aa498d4.cfm

Shawn
  • 4,758
  • 1
  • 20
  • 29
  • I could be wrong, but got the impression it's existing code that might not be feasible to update .. Agreed a lot of stuff is possible using newer tags, though CF might still be using that lib beneath the hood if they're still bundling it with 2018 ;-). – SOS May 30 '19 at 18:53
  • I actually don't know what library `cfpdf` is using. Though I would hope that if they are still using iText, they'd have upgraded it to a newer version. The one using the `lowagie` namespace is pretty old, isn't it? Regardless, I still think that, in general, it would probably be worth the effort to refactor code that is using out-of-date libraries, especially if already editing code that is touching those libraries. – Shawn May 30 '19 at 19:03
  • Yeah, I'm not against refactoring, assuming it's feasible (not sure how extensive the code is). Just trying to help get their code running in the interim. *I would hope that if they are still using iText, they'd have upgraded it to a newer version. The one using the lowagie namespace is pretty old, isn't it?* I don't know what it uses either, but the fact that the lib can still be loaded on a brand new install of 2018 isn't an encouraging sign... :-/ – SOS May 30 '19 at 20:06
  • @Ageax Very true. – Shawn May 30 '19 at 20:10