Java modules b0rked when installed from Ubuntu PPA

[Chris Hillery]

This is at least true of the read-pdf module, I haven't yet checked others.

Initial symptom: Running a query using the module produces a NoClassDefFoundError for org/apache/pdfbox/pdmodel/encryption/DecryptionMaterial. This class does exist in the libpdfbox-java Ubuntu package in /usr/share/java/pdfbox.jar, so apparently that is not put onto Zorba's classpath.

Moreover, in /usr/lib/zorba/jars, there are broken symlinks for commons-logging.jar, fontbox.jar, jempbox.jar, and pdfbox.jar (they all point to eg. pdfbox-1.7.0.jar in the same directory, but that file does not exist). Our module package should not include those jars anyway, and they certainly shouldn't be symlinks to non-existent files.

Also in /usr/lib/zorba/jars, there exists zorba_read-pdf_module-classpath.txt which contains "pdfbox.jar", "fontbox.jar", etc. This should instead contain "/usr/share/java/pdfbox.jar", etc.

This is a problem either with the recipe used to build the Ubuntu package, or else with the build scripts when building a module stand-alone (not as part of a Zorba build). When you build and install Zorba with the read-pdf module, the lib/zorba/jars directory is correct (no broken symlinks, no copies of pdfbox.jar etc, and the classpath.txt file contains absolute paths for those external jars).

[Juan Zacarias (juan457)]

I tested the installed read-pdf and this are my observations:

>Moreover, in /usr/lib/zorba/jars, there are broken symlinks for commons-logging.jar,
>fontbox.jar, jempbox.jar, and pdfbox.jar (they all point to eg. pdfbox-1.7.0.jar in the
>same directory, but that file does not exist). Our module package should not include
>those jars anyway, and they certainly shouldn't be symlinks to non-existent files.

We don't include those jars, we set the dependencies to those jars and the package manager makes sure you have them before installing if you don't it gives you a message if you want to install them, and use the packages of each jar and install them.

>This is a problem either with the recipe used to build the Ubuntu package, or else with the build
>scripts when building a module stand-alone (not as part of a Zorba build). When you build and
>install Zorba with the read-pdf module, the lib/zorba/jars directory is correct (no broken symlinks,
>no copies of pdfbox.jar etc, and the classpath.txt file contains absolute paths for those external jars).

I took a look and I get other errors, I get :

operating system error [zerr:ZOSE0005]: "/usr/lib/zorba/com/zorba-xquery/www/modules/libread-pdf_1.0.so": error loading dynamic library: libjvm.so: cannot open shared object file: No such file or directory

So I tested with building the module as stand alone and it threw the same error so I am guessing the problem is that the module is not designed to work correctly as a stand alone module. as stand alone module, it does not even compile correctly (I will propose for merge a branch that fixes the building process but doesn't solve this bug it just allows the compilation of the module as stand alone)

I will subscribe Cezar to this bug report to see if he knows what could be wrong since I have no clue of how does the java modules work.

[Cezar Andrei (cezar-andrei)]

I'm not sure that this is a valid scenario: to have a module built against a Zorba that was installed from binaries.

First you need to make sure the install finds and uses correctly java.
Second, as Chris said you don't need to symlink jars or anything like this, just use the correct classpath.txt file that build used.

[Juan Zacarias (juan457)]

>I'm not sure that this is a valid scenario: to have a module built against a
>Zorba that was installed from binaries.

Not sure what you mean by a valid scenario, but one of the ideas of making the external modules the way they are, was to help developers build modules without the need of the source code of zorba, so all the macros and tools used for developing external modules are available as part of the external module API of zorba in the installed version. Also a reason for util-jvm I would guess, since I am not sure of what does util-jvm actually does.

>First you need to make sure the install finds and uses correctly java.

The installer does find and use java correctly thanks to util-jvm that's why previous modules using this tool are working right now, so I will not find this an issue. The symlink thing could be the problem but again my lack of knowledge of java modules is big and I have no clue where in the code of the module this is done.

>Second, as Chris said you don't need to symlink jars or anything like this, just use
>the correct classpath.txt file that build used.

And sorry but my knowledge of java is really low on how it works, but for the installers I don't do anything special if there is a symlink done it is done somewhere in the module, the installer is just like a mere make install done remotely.

The theory on how a ubuntu installer will work is, if it works as a stand alone module it will work as a deb package.
And the pdf module sadly does not work if built against an installed version of zorba or a version of zorba built in a different folder. So in order to make the installer work we need to fix the stand alone version of the module, any idea how we can do that? And what do you mean by use the correct classpath.txt?

[Cezar Andrei (cezar-andrei)]

Chris is the expert here, he knows in more detail how the CMake scripts work.
But as a high level a java module is very similar to a regular module with a few additions:
  - It has a dynamic library just like the other modules.
  - It has a dependency on util-jvm lib and
  - it has a classpath to find the required jars.

The util-jvm library it just like any other module library, it is dependent of libjvm.so. This lib is the code that manages the jvm, knows how to start, stop and talk to the jvm. From the installer perspective should be just like couchbase module.

Chris, am I correct? If so maybe just ZORBA_FIND_JAR() has to be available to the module.

[Juan Zacarias (juan457)]

I see, that would be something that makes some sense, then I would make
some changes to have ZORBA_FIND_JAR available even when zorba is installed
and see if this fixes the problem.

On Thu, Feb 28, 2013 at 2:08 PM, Cezar Andrei <email address hidden>wrote:

> Chris is the expert here, he knows in more detail how the CMake scripts
> work.
> But as a high level a java module is very similar to a regular module with
> a few additions:
> - It has a dynamic library just like the other modules.
> - It has a dependency on util-jvm lib and
> - it has a classpath to find the required jars.
>
> The util-jvm library it just like any other module library, it is
> dependent of libjvm.so. This lib is the code that manages the jvm, knows
> how to start, stop and talk to the jvm. From the installer perspective
> should be just like couchbase module.
>
> Chris, am I correct? If so maybe just ZORBA_FIND_JAR() has to be
> available to the module.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1102881
>
> Title:
> Java modules b0rked when installed from Ubuntu PPA
>
> Status in Zorba - The XQuery Processor:
> New
>
> Bug description:
> This is at least true of the read-pdf module, I haven't yet checked
> others.
>
> Initial symptom: Running a query using the module produces a
> NoClassDefFoundError for
> org/apache/pdfbox/pdmodel/encryption/DecryptionMaterial. This class
> does exist in the libpdfbox-java Ubuntu package in
> /usr/share/java/pdfbox.jar, so apparently that is not put onto Zorba's
> classpath.
>
> Moreover, in /usr/lib/zorba/jars, there are broken symlinks for
> commons-logging.jar, fontbox.jar, jempbox.jar, and pdfbox.jar (they
> all point to eg. pdfbox-1.7.0.jar in the same directory, but that file
> does not exist). Our module package should not include those jars
> anyway, and they certainly shouldn't be symlinks to non-existent
> files.
>
> Also in /usr/lib/zorba/jars, there exists zorba_read-pdf_module-
> classpath.txt which contains "pdfbox.jar", "fontbox.jar", etc. This
> should instead contain "/usr/share/java/pdfbox.jar", etc.
>
> This is a problem either with the recipe used to build the Ubuntu
> package, or else with the build scripts when building a module stand-
> alone (not as part of a Zorba build). When you build and install Zorba
> with the read-pdf module, the lib/zorba/jars directory is correct (no
> broken symlinks, no copies of pdfbox.jar etc, and the classpath.txt
> file contains absolute paths for those external jars).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zorba/+bug/1102881/+subscriptions
>

--
-JuanZa