Q:
My
goal is to implement this within a stand-alone web application using jetty to
provide conversion of pdf files into xps. The implementation seems fairly
simple and straight-forward. Going off of the "ConvertTest"
sample included in the SDK, I have the following within my conversion method:
PDFNet.initialize();
PDFDoc doc = new
PDFDoc(getPdfLocal());
Convert.toXps(doc,
outputFile.getAbsolutePath());
doc.close();
After
deploying and starting the Jetty server, the first request results in:
java.lang.UnsatisfiedLinkError: no PDFNetC in java.library.path
All
subsequent requests result in:
java.lang.NoClassDefFoundError: Could not initialize class
pdftron.PDF.PDFNet
These
errors are being thrown from the initialize() method.
Both
the PDFNet.jar and libPDFNetC.so are in the lib/include subfolder of my project
war.
PDFNetC.dll
was not included in the download for 64-bit linux, and I assume that is only
needed for a Windows install, but just in case I downloaded the Windows version
and copied the PDFNetC.dll and PDFNetC.lib into the lib/include folder as well,
but it did not make any difference.
I am
able to run the sample by executing RunTest.sh from the ConvertTest and it
works satisfactorily.
Not
able to get the project to work using a packaged .war file, I extracted the war
and attempted to run it unpackaged. I verified that Jetty is being run
with the -Djava.library.path= option pointing to the full path of the
lib/include folder where both the .jar and .so files reside. This
however, did not make any difference. I am still getting the same errors.
----------
A:
There
are a couple of reasons why you are getting this problem, both leading to the
Java binary not being able to load PDFNetC on runtime:
1. The library path Java sees does not contain libPDFNetC.so. In your case,
however, you mentioned that you set the java.library.path to the directory that
contains libPDFNetC.so. An alternative way of setting the library path is to
install the shared object to the system wide library directory (i.e. /usr/lib
or /usr/local/lib) then run the application again.
2. If the previous solution does not work, then it is likely that there is
a mistmatch in architectures. If you are running JRE 32-bit mode, then you will
need 32-bit PDFNetC. Likewise for 64-bit versions. You can check your JRE
version by invoking "java -version". It should either say mixed-mode
(32-bit) or 64-bit. Please try using the appropriate PDFNetC to match the
reported architecture.
With these information in mind, I would like to clarify a number of things
that are relevant to your situation:
a.) PDFNetC.dll will not work on Linux directly. Linux uses ELF format
(.so) while Windows uses PE format (.dll). These are two different formats.
Therefore, your assumption is correct that PDFNetC.dll is for Windows only.
b.) Can you please verify the architecture of the JRE that your Jetty uses?
As mentioned in point #2 above, you may need to use the 32-bit version of
PDFNetC. It could be possible that your Jetty uses a different Java binary from
the one you used to run the ConvertTest sample. In this case the solution would be to use 32-bit version even though your app runs on 64-bit OS.