Subject: [Pljava-dev] build/deploy question

From: bgiles at coyotesong.com (Bear Giles)
Date: Thu, 6 Aug 2015 13:51:21 -0600

I'm exploring wrapping pljava in a postgresql extension and have something
that loads it when I type 'create extension pljava' but it barfs when I try
to actually do something - it gives me 'java.lang.NoClassDefFoundError:
org/postgresql/pljava/internal/Backend". I know I have the infrastructure
in place though since I can list the tables in the sqlj schema.

I built the .so using 'mvn install'. Do I need to do anything else? I tried
USE_GCJ=1 in front but that didn't change the size of the .so file.

BTW the control file specifies libjvm as a dependency. I added an entry to
/etc/ld.so.conf.d so my java8 shlib is on the search path.

This is postgresql 9.4.4 and Ubuntu 14.10? (utopic).

Bear

BTW I think I have figured out how to wrap subsequent jar files in an
extension as well. I can't be sure since I get that error when I execute
them but the pgxn makefile is putting everything in the right place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20150806/32237db8/attachment.html>

---

From: chap at anastigmatix.net (Chapman Flack)
Date: Sat, 05 Sep 2015 17:28:06 -0400

Bear Giles wrote:

> that loads it when I type 'create extension pljava' but it barfs when I
> try to actually do something - it gives me
>'java.lang.NoClassDefFoundError: org/postgresql/pljava/internal/Backend".

That's the usual symptom of not having pljava.classpath properly set
to find the pljava.jar file.

I do see that, in the "installing as extension" docs you contributed,
you have a line in the script to set pljava.classpath from sql. That
probably makes things work in the same session that has run
CREATE EXTENSION, but doesn't affect other or future sessions.

The usual way of getting the pljava.classpath setting to be cluster-wide
would be to add it to postgresql.conf (which seems imperfect, as it doesn't
completely fit in the extension model, but it may be the best we can do).

Since 9.4 there is an ALTER SYSTEM command like a persistent SET, that can
only be run by a superuser, and doesn't take effect until the next HUP
(I guess a session that already has to be superuser can call
pg_reload_conf). That seems more extension-friendly ... but I see that it
can't be run inside a transaction, and I would not be surprised if extension
scripts are being run inside a transaction ....

-Chap