Forum Discussion

JoseVazquez-1's avatar
JoseVazquez-1
Occasional Contributor
9 years ago

Stripping data of pdf files - used to work, now has error "Object doesn't support this action"

I have the below script (written by an engineer that left 3 months ago), that was used to strip data from a pdf file, for the purposes of verifying that the contents are as expected.  It always worked without errors.  A few weeks ago (the script was never changed) it stopped working, and I get an error:  "Object doesn't support this action".

 

Stepping through the debugger, the error comes from the below line:

"

var docObj =JavaClasses.org_apache_pdfbox_pdmodel.PDDocument.load_3(strFileName);

"

I have searched, and I have trouble finding any information on ".load_3".  Changing it to "load" causes the same error.

The code seems to invoke a Java function, and as we all know, JAVA updates automatically. 

 

Just wondering, has anyone had any experience with this JAVA function, or could explain why the sudden break?

 

 

The full stripping script is below:

 

"

// Strips and returns text from a pdf file in C:\ called rpt.pdf
function stripText()
{
try{
//var strFileName = Sys.OleObject("WScript.Shell").SpecialFolders("Desktop") + "\\rpt.pdf"; //"C:\\Users\\rnd.AU\\Desktop\\rept.pdf";
var strFileName = ProjectSuite.Variables.XCEL_PATH + "\\rpt.pdf";
Log.Message(strFileName);

// var doc=JavaClasses.

// Load the PDF file to the PDDocument object
var docObj =JavaClasses.org_apache_pdfbox_pdmodel.PDDocument.load_3(strFileName);
// SUDDEN ISSUE WITH THE ABOVE LINE
// Create text stripper object
var textStripperObj = JavaClasses.org_apache_pdfbox_util.PDFTextStripper.newInstance();

// strip text from the entire document
var text = textStripperObj.getText_2(docObj);

// Voila!
Log.Message("Text from rpt.pdf stripped...");
Log.Message (text);
return(text);
}
catch (e){
Log.Error(e.description);

}

}

"

  • The file "pdfbox-app-1.8.8.jar" was reloaded (in case it was corrupted), and this did not solve the issue.

     

     

    Issue was eventually solved.

     

    Step 1.

    Updated the JRE (Java Runtime Environment) to the latest version.

     

    Step 2.


    In the Menu Bar, select "Tools", then "Options". Go to "Engines", then "Java Bridge".
    Select the latest JVM (java Virtual Machine) path. See picture "TestComplete-JAVA-Bridge-B.JPG".

     

     

    Step 3.


    Under the Project "Properties", "java Bridge", both the "Java Classes" and the "Class Paths" were deleted, then reloaded.  See picture "TestComplete-JAVA-Bridge.JPG".

     

     

    These two steps fixed the issue.


    Test Complete does not automatically JVM path after a Java update.

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3

    Hi Jose,

     

    > [...] JAVA updates automatically.

    First note: There were similar discussions on the forum related to the automatic updates of web browsers and my personal opinion is that with the enabled auto updates you are getting uncontrollable test environment and this is far not always the best approach.

    Indeed, if your company explicitly declares that it supports the latest and only the latest version of, say, Java and accepts responsibility for any reported problems that were caused by the just released Java version (even if new Java was released in the midnight in the middle of the weekend and the issue report arrived 5 minutes later after this), then you have no choice but continuously test on the latest Java version available (what about betas?).

    Otherwise, even if you try your best to support the latest version as soon as possible, you must keep your test environment stable and controllable. Disable automatic updates. When the new version is released, create a new documented test environment, check if the environment itself works, check if your tested application can at least start on this new environment, check if your tests still work on the new environment, analyze results and only after that you may dispose of your previous test environment if needed.

    With the approach above, in the worst case you still will be able to execute your tests for the new builds of your tested application on the previous test environment and provide the results. But in case of uncontrollable test environment you are at risk of been completely blocked (like you are now) and not been able to provide results for both new and previous test environments.

     

    As for your actual question, it looks like that the case is not updated Java, but updated version of PDFBox library that is used in your code.

    As the only thing that you need is to extract text from pdf file, I would recommend to rollback pdfbox library from v.2.x to 1.x.

    Otherwise, you may check this thread (https://community.smartbear.com/t5/Desktop-Testing/Compare-pdf-files/m-p/122418#M6672) and try to adjust your test code.

     

     

    • JoseVazquez-1's avatar
      JoseVazquez-1
      Occasional Contributor

      The file "pdfbox-app-1.8.8.jar" was reloaded (in case it was corrupted), and this did not solve the issue.

       

       

      Issue was eventually solved.

       

      Step 1.

      Updated the JRE (Java Runtime Environment) to the latest version.

       

      Step 2.


      In the Menu Bar, select "Tools", then "Options". Go to "Engines", then "Java Bridge".
      Select the latest JVM (java Virtual Machine) path. See picture "TestComplete-JAVA-Bridge-B.JPG".

       

       

      Step 3.


      Under the Project "Properties", "java Bridge", both the "Java Classes" and the "Class Paths" were deleted, then reloaded.  See picture "TestComplete-JAVA-Bridge.JPG".

       

       

      These two steps fixed the issue.


      Test Complete does not automatically JVM path after a Java update.

      • MulgraveTester's avatar
        MulgraveTester
        Frequent Contributor

        Thanks for the solution. I had exactly the same issue when testing pdf reports - Code that used to work failed with

        Object doesn't support this action: 'JavaClasses.org_apache_pdfbox_pdmodel'.

         

        Looks like Java have moved their code again since your post and no longer use the x86 program folder for 64 bit OS:

        C:\Program Files (x86)\Java\jre1.8.0_131\bin\client\jvm.dll

        is now

        C:\Program Files\Java\jre1.8.0_131\bin\server\jvm.dll

    • JoseVazquez-1's avatar
      JoseVazquez-1
      Occasional Contributor

      Hi Alex,

       

       

      Many thanks for the reply.

       

      It took me a while figure out where the PDFBox file pointer is.

       

      I found it in the Project Properties, under the section Java Bridge.  The path points to the executable "pdfbox-app-1.8.8.jar", see the attached screen print PDF-Box2.PNG.  So, it appears that Testcomplete is already using the PDFBox 1.X version, as you have suggested, unless I am looking at the wrong setting.

       

      Based upon this, do you have any other suggestions?

       

       

       

      Thanks heaps!

       

       

      Jose

       

       

      ~~~~~~~~~~~~~~~~~~~~

       

       

    • JoseVazquez-1's avatar
      JoseVazquez-1
      Occasional Contributor

      Hi Alex,

       

       

       

      Many thanks for the reply.

       

      Took me a while to find where the path was to call the PDFBox file, I finally did - In the Project Properties, under section "Java Bridge".  The path already points to version 1.1.8, as you can see from the attached file "PDF-Box3.png", which is what you suggested to do/change to.  Unless I am missing something, I have no idea what to do now.  Any suggestions as for the next step?

       

       

      Thanks heaps!

       

       

      Jose

       

       

      ~~~~~~~~~~~~~~~~~~~~~~~