From: | chap at anastigmatix(dot)net (Chapman Flack) |
---|---|
To: | |
Subject: | [Pljava-dev] build/deploy question |
Date: | 2015-09-05 21:28:06 |
Message-ID: | 55EB5E66.6070905@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pljava-dev |
Bear Giles wrote:
> 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".
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Brewer | 2015-09-08 19:02:44 | [Pljava-dev] Pl/Java package in Ubuntu |
Previous Message | Chapman Flack | 2015-09-05 21:09:06 | [Pljava-dev] PL/Java version number, and a module name |