0 Replies Latest reply on Sep 10, 2013 2:28 PM by CHBedford

    CFPDFFORM fails to generate valid XML

    CHBedford Level 1

      I've been trying to figure out exactly why this tag has been consistently failing on one of my two production boxes for 3 weeks, with very limited success.

       

      On system one, it works fine, and generates the following for a standard PDF:

      <?xml version="1.0" encoding="UTF-8"?>

      <xfdf xmlns="http://ns.adobe.com/xfdf/" xml:space="preserve">

           <fields>

                <field name="HIGH SCHOOL DIPLOMA"/>

                ...fields deleted for brevity...

                <field name="Print"/>

           </fields>

           <ids original="6F185C876244254CBA5693F8CDC7D0AA" modified="25576F3D95DBC54B87BDFC8CCAAE408D"/>

      </xfdf>

       

      On system two, however, the XML generated looks a little different:

      <?xml version="1.0" encoding="UTF-8"?>

      <xfdf xml:xml:space="preserve">

           <fields>

                <field name="HIGH SCHOOL DIPLOMA"/>

                ...fields deleted for brevity...

                <field name="Print"/>

           </fields>

           <ids original="6F185C876244254CBA5693F8CDC7D0AA" modified="25576F3D95DBC54B87BDFC8CCAAE408D"/>

      </xfdf>

       

      This happens for every single pdf file we have tried.

       

      Here's the code to generate the xml:

      <cfpdfform action="read" XMLdata="tempvar" source="/.../cool.pdf">

      </cfpdfform>

      <cfdump var="#tempvar#">

       

      We are running in JBOSS EWP 5.2 as an expanded CF10 cfusion.war on patch level 11 with Java 1.7.0_21 on a RHEL 5.9

       

      I have reinstalled Java, Jboss, and cold fusion from scratch, and even as a last ditch effort copied the whole tree from box one to box two to try to resolve the issue, all to no effect.  I'm looking for direction on how we can proceed and which jar we have to look into to resolve the issue, or what system level utility can be used to further diagnose the problem.

       

      We do have a couple work arounds, but none of them without significant level of effort, and time required to move to the new toolset in our existing code.