public inbox for [email protected]help / color / mirror / Atom feed
PL/Java 1.5.1_BETA2 18+ messages / 3 participants [nested] [flat]
* PL/Java 1.5.1_BETA2 @ 2018-09-10 18:04 Chapman Flack <[email protected]> 0 siblings, 1 reply; 18+ messages in thread From: Chapman Flack @ 2018-09-10 18:04 UTC (permalink / raw) To: [email protected]; pgsql-pkg-yum Hello packagers, There is a PL/Java 1.5.1_BETA2 release at github: https://github.com/tada/pljava/releases/tag/V1_5_1b2 A lot of time has passed since BETA1, so there is more new functionality than would be typical for a BETA2. In retrospect, I should have bumped the number higher and called it another beta1, which would allow it to be announced on pgsql-announce, but that policy had slipped my mind. Anyway, as poorly announced as it may be, there is a new beta release. It would be great if there could be packages for it. Thanks! -Chap ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-15 20:32 Christoph Berg <[email protected]> parent: Chapman Flack <[email protected]> 0 siblings, 1 reply; 18+ messages in thread From: Christoph Berg @ 2018-09-15 20:32 UTC (permalink / raw) To: Chapman Flack <[email protected]>; +Cc: [email protected]; pgsql-pkg-yum Re: Chapman Flack 2018-09-10 <[email protected]> > Hello packagers, > > There is a PL/Java 1.5.1_BETA2 release at github: > https://github.com/tada/pljava/releases/tag/V1_5_1b2 Hi Chap, you got me interested again :) I tried building pljava, but I seem to fail at a very early stage: $ JAVA_HOME=/usr/lib/jvm/default-java/ PATH=/usr/lib/jvm/default-java/bin:$PATH mvn compile [...] [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ pljava-api --- [INFO] Compiling 24 source files to /srv/projects/postgresql/pljava/postgresql-pljava/pljava-api/target/classes [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] Failure executing javac, but could not parse the error: Fatal Error: Unable to find package java.lang in classpath or bootclasspath [INFO] 1 error [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] PostgreSQL PL/Java 1.5.1-BETA2 ..................... SUCCESS [ 0.023 s] [INFO] PL/Java API ........................................ FAILURE [ 0.934 s] [INFO] PL/Java backend Java code .......................... SKIPPED [INFO] PL/Java backend native code ........................ SKIPPED [INFO] PL/Java Deploy ..................................... SKIPPED [INFO] PL/Java Ant tasks .................................. SKIPPED [INFO] PL/Java examples ................................... SKIPPED [INFO] PL/Java packaging 1.5.1-BETA2 ...................... SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.931 s [INFO] Finished at: 2018-09-15T22:26:25+02:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project pljava-api: Compilation failure [ERROR] Failure executing javac, but could not parse the error: [ERROR] Fatal Error: Unable to find package java.lang in classpath or bootclasspath [...] openjdk-10-jdk is installed. Any idea what is missing? Christoph ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-15 21:03 Chapman Flack <[email protected]> parent: Christoph Berg <[email protected]> 0 siblings, 1 reply; 18+ messages in thread From: Chapman Flack @ 2018-09-15 21:03 UTC (permalink / raw) To: Christoph Berg <[email protected]>; [email protected]; pgsql-pkg-yum On 09/15/18 16:32, Christoph Berg wrote: > Fatal Error: Unable to find package java.lang in classpath or bootclasspath > ... > openjdk-10-jdk is installed. Any idea what is missing? With Java 9, a completely new modular structure was brought to the JDK, with deep implications for build procedures. I will have to rework the build process heavily for a future PL/Java release, but for 1.5.1, I have not. So, it needs a Java 8 JDK (or 7, or 6, but let's just say 8) to build. Once built, it will _run_ on later Java runtimes (and users can write PL/Java functions using the latest language features, compile them with later JDKs, and run them in PL/Java, as long as it is running on a new- enough runtime). The Java runtime that actually gets used, at runtime, is determined by the pljava.libjvm_location variable, which can be given a default at build time with -Dpljava.libjvmdefault=.... So if you are packaging for a platform where you know Java 10 will be the default, and you know what the conventional path to its libjvm.so will be, then by all means, use -Dpljava.libjvmdefault= to build in that default for use at runtime. But the build, for now, must be done with 8. There is a new(-ish?) page in the documentation with information intended for packagers: http://tada.github.io/pljava/build/package.html -Chap ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-16 20:18 Christoph Berg <[email protected]> parent: Chapman Flack <[email protected]> 0 siblings, 2 replies; 18+ messages in thread From: Christoph Berg @ 2018-09-16 20:18 UTC (permalink / raw) To: Chapman Flack <[email protected]>; +Cc: [email protected] Re: Chapman Flack 2018-09-15 <[email protected]> > On 09/15/18 16:32, Christoph Berg wrote: > > Fatal Error: Unable to find package java.lang in classpath or bootclasspath > > ... > > openjdk-10-jdk is installed. Any idea what is missing? > > With Java 9, a completely new modular structure was brought to the JDK, > with deep implications for build procedures. I will have to rework the > build process heavily for a future PL/Java release, but for 1.5.1, I > have not. > > So, it needs a Java 8 JDK (or 7, or 6, but let's just say 8) to build. Ok, openjdk-8 worked, thanks. I was actually skimming the docs for the supported Java versions, but couldn't find anything, so went with the default-jdk in Debian, which is 10. A note in the docs would be appreciated, or if it's already in there, it needs to be more visible. > Once built, it will _run_ on later Java runtimes (and users can write > PL/Java functions using the latest language features, compile them with > later JDKs, and run them in PL/Java, as long as it is running on a new- > enough runtime). > > The Java runtime that actually gets used, at runtime, is determined by > the pljava.libjvm_location variable, which can be given a default at > build time with -Dpljava.libjvmdefault=.... I got that working just fine on sid/amd64, but have a series of problems on i386 (i.e. 32-bit x86). The build is running with -Dpljava.libjvmdefault=/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so, but then actually using the extension yields this: https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/3/architecture=i386,distribution=sid/ 20:14:15 + psql -c 'CREATE EXTENSION pljava' 20:14:15 WARNING: Java virtual machine not yet loaded 20:14:15 DETAIL: /usr/lib/jvm/java-8-openjdk-1/jre/lib/1/server/libjvm.so: cannot open shared object file: No such file or directory 20:14:15 HINT: SET pljava.libjvm_location TO the correct path to the jvm library (libjvm.so or jvm.dll, etc.) i.e. it's replacing both occurrences of "i386" by "1". If I manually fix that, there's more weirdness: (same session was running "create extension pljava" earlier) # set pljava.libjvm_location = '/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so'; HINWEIS: 00000: PL/Java loaded DETAIL: versions: PL/Java native code (1.5.1-BETA2) PL/Java common code (1.5.1-BETA2) Built for (PostgreSQL 10.5 (Debian 10.5-2~30.git84cd21f.pgdg+1) on i686-pc-linux-gnu, compiled by gcc (Debian 8.2.0-4) 8.2.0, 32-bit) Loaded in (PostgreSQL 10.5 (Debian 10.5-2~30.git84cd21f.pgdg+1) on i686-pc-linux-gnu, compiled by gcc (Debian 8.2.0-4) 8.2.0, 32-bit) OpenJDK Runtime Environment (1.8.0_181-8u181-b13-1-b13) OpenJDK Server VM (25.181-b13, mixed mode) ORT: initsequencer, Backend.c:597 HINWEIS: 00000: PL/Java successfully started after adjusting settings TIP: The settings that worked should be saved (using ALTER DATABASE postgres SET ... FROM CURRENT or in the "/home/cbe/tmp/pg_virtualenv.m9FB0r/postgresql/10/regress/postgresql.conf" file). For a reminder of what has been set, try: SELECT name, setting FROM pg_settings WHERE name LIKE 'pljava.%' AND source = 'session' ORT: initsequencer, Backend.c:639 HINWEIS: 00000: PL/Java load successful after failed CREATE EXTENSION DETAIL: PL/Java is now installed, but not as an extension. TIP: To correct that, either COMMIT or ROLLBACK, make sure the working settings are saved, exit this session, and in a new session, either: 1. if committed, run "CREATE EXTENSION pljava FROM unpackaged", or 2. if rolled back, simply "CREATE EXTENSION pljava" again. ORT: initsequencer, Backend.c:654 SET Why does tell me that this installation is not from an extension? Proceeding to load the examples: # SELECT sqlj.install_jar('file:/usr/share/postgresql/10/pljava/pljava-examples-1.5.1-BETA2.jar', 'examples', true) ; HINWEIS: 42809: Rückgabetyp javatest.udtscalariotest ist nur eine Hülle ORT: compute_return_type, functioncmds.c:105 [...] ORT: Java_org_postgresql_pljava_internal_Backend__1log, Backend.c:1621 INFO: 00000: 16 Sep 18 19:54:06 org.postgresql.pljava.example.LoggerTest timestamptz roundtrip passes ORT: Java_org_postgresql_pljava_internal_Backend__1log, Backend.c:1621 INFO: 00000: 16 Sep 18 19:54:09 org.postgresql.pljava.example.LoggerTest all Unicode codepoint ranges roundtripped successfully. ORT: Java_org_postgresql_pljava_internal_Backend__1log, Backend.c:1621 Server beendete die Verbindung unerwartet Das heißt wahrscheinlich, dass der Server abnormal beendete bevor oder während die Anweisung bearbeitet wurde. Die Verbindung zum Server wurde verloren. Versuche Reset: Fehlgeschlagen. ... it crashes. > There is a new(-ish?) page in the documentation with information intended > for packagers: > > http://tada.github.io/pljava/build/package.html Aye, I remember having seen that 2.5 years ago when I last tried looking at 1.5. Another question: Docs say mvn -Dpgsql.pgconfig=... java -Dpgconfig=/local/pgsql/bin/pg_config -jar pljava-packaging/... I had first tried mvn -Dpgconfig, which didn't work - is it really two different variable names? And is -Dpgconfig even used if for the installer, when -Dpgconfig.pkglibdir and -Dpgconfig.sharedir are given? I need to point these to debian/postgresql-$version-pljava/usr/... A "DESTDIR" mechanism would be nice to have here. On stretch/amd64, install_jar fails on 9.6 (9.3/4/5 worked): 20:07:05 + psql -c 'CREATE EXTENSION pljava' 20:07:05 CREATE EXTENSION 20:07:05 + psql -c 'SELECT sqlj.install_jar('\''file:/usr/share/postgresql/9.6/pljava/pljava-examples-1.5.1-BETA2.jar'\'', '\''examples'\'', true)' [...] 20:07:07 INFO: 16 Sep 18 18:07:07 org.postgresql.pljava.management.Commands Type id = OID(16686) 20:07:07 ERROR: java.lang.ClassNotFoundException: org.postgresql.pljava.example.annotation.ComplexTuple 20:07:07 CONTEXT: SQL statement "SELECT javatest.assertHasValues( CAST('(1,2)' AS javatest.complextuple), 1, 2)" https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/3/architecture=amd64,distribution=stre... On sid/ppc64el, compilation dies: https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/3/architecture=ppc64el,distribution=si... 20:00:43 [ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.2.3:nar-validate (default-nar-validate) on project pljava-so: NAR: One of two things may be wrong here: 20:00:43 [ERROR] 1. <Name> tag is missing inside the <Linker> tag of your NAR configuration 20:00:43 [ERROR] 2. no linker is defined in the aol.properties file for 'ppc64le.Linux.linker' Is that a problem in pljava, or a general java-on-that-platform problem? (I can open GitHub issues for any of these items if you confirm which make sense.) Christoph ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-16 20:27 Christoph Berg <[email protected]> parent: Christoph Berg <[email protected]> 1 sibling, 1 reply; 18+ messages in thread From: Christoph Berg @ 2018-09-16 20:27 UTC (permalink / raw) To: Chapman Flack <[email protected]>; [email protected] Re: To Chapman Flack 2018-09-16 <[email protected]> > On stretch/amd64, install_jar fails on 9.6 (9.3/4/5 worked): > > 20:07:05 + psql -c 'CREATE EXTENSION pljava' > 20:07:05 CREATE EXTENSION > 20:07:05 + psql -c 'SELECT sqlj.install_jar('\''file:/usr/share/postgresql/9.6/pljava/pljava-examples-1.5.1-BETA2.jar'\'', '\''examples'\'', true)' > [...] > 20:07:07 INFO: 16 Sep 18 18:07:07 org.postgresql.pljava.management.Commands Type id = OID(16686) > 20:07:07 ERROR: java.lang.ClassNotFoundException: org.postgresql.pljava.example.annotation.ComplexTuple > 20:07:07 CONTEXT: SQL statement "SELECT javatest.assertHasValues( CAST('(1,2)' AS javatest.complextuple), 1, 2)" > > https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/3/architecture=amd64,distribution=stre... The problem on bionic/amd64 is similar, here 9.4 fails after 9.3 passed the tests: 20:06:37 + psql -c 'SELECT sqlj.install_jar('\''file:/usr/share/postgresql/9.4/pljava/pljava-examples-1.5.1-BETA2.jar'\'', '\''examples'\'', true)' [...] 20:06:38 ERROR: java.lang.ClassNotFoundException: org.postgresql.pljava.example.annotation.Point 20:06:38 CONTEXT: SQL statement "SELECT javatest.assertHasValues(CAST('(1,2)' AS point), 1, 2)" https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/3/architecture=amd64,distribution=bion... Also, does it have to be that verbose all the time, even if things worked? This was all on openjdk-8. On jessie/amd64, openjdk-7 is used: 20:22:24 + java -Dpgsql.pgconfig=/usr/lib/postgresql/9.3/bin/pg_config -Dpgconfig.pkglibdir=debian/postgresql-9.3-pljava/usr/lib/postgresql/9.3/lib -Dpgconfig.sharedir=debian/postgresql-9.3-pljava/usr/share/postgresql/9.3 -jar build-9.3/pljava-pg9.3-amd64-Linux-gpp.jar 20:22:25 Exception in thread "main" java.lang.ClassCastException: sun.org.mozilla.javascript.ConsString cannot be cast to java.lang.String 20:22:25 at org.gjt.cuspy.JarX.extract(JarX.java:670) 20:22:25 at org.gjt.cuspy.JarX.extract(JarX.java:445) 20:22:25 at org.gjt.cuspy.JarX.main(JarX.java:419) https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/3/architecture=amd64,distribution=jess... The full set of dist/architecture combinations can be see at https://pgdgbuild.dus.dg-i.net/job/postgresql-pljava-binaries/3/ Please tell me which issues you want a problem report on GitHub for :) Cheers, Christoph ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-16 21:36 Chapman Flack <[email protected]> parent: Christoph Berg <[email protected]> 1 sibling, 2 replies; 18+ messages in thread From: Chapman Flack @ 2018-09-16 21:36 UTC (permalink / raw) To: Christoph Berg <[email protected]>; [email protected] On 09/16/18 16:18, Christoph Berg wrote: > i.e. it's replacing both occurrences of "i386" by "1". Ok, that's irritating. I can guess what is happening. I implement the -Dpljava.libjvmdefault by passing the string into cpp with a -D, and that gets converted to a string using the CppAsString2 macro, and that apparently is not protected from expansion of other macros, and I bet something is defining i386 to be 1. Phooey. I don't know if that will be easy to fix using cpp. An alternative would be to pass it to cpp already quoted according to C rules, but that would be somewhat ugly to express in a Maven build script. > (same session was running "create extension pljava" earlier) > # set pljava.libjvm_location = '/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so'; > HINWEIS: 00000: PL/Java load successful after failed CREATE EXTENSION > DETAIL: PL/Java is now installed, but not as an extension. > TIP: To correct that, either COMMIT or ROLLBACK, make sure the working settings are saved, exit this session, and in a new session, either: 1. if committed, run "CREATE EXTENSION pljava FROM unpackaged", or 2. if rolled back, simply "CREATE EXTENSION pljava" again. > ORT: initsequencer, Backend.c:654 > > Why does tell me that this installation is not from an extension? Your original CREATE EXTENSION command did not succeed, reporting the error trying to load the library. Your SET command to correct the library name completed the installation of PL/Java, but at that point it was no longer within a CREATE EXTENSION command, so the various functions, tables, etc., have just been installed 'loose' (exactly as they would if you were installing in 9.0 or earlier with no 'extension' mechanism). The TIP describes how to proceed so they will all be grouped together as a named extension, just as would have happened had the jvm path been correct when the CREATE EXTENSION command was first given. > Proceeding to load the examples: > Server beendete die Verbindung unerwartet Is there anything in the server log with details of the crash? In many cases there will be a lengthy message from the JVM in the server log, and that message will contain a file name (something like /tmp/hs_err_pidnnnn.log) which will contain *even more* detail. I would be interested to see that. Was this still on i386 ? > Another question: Docs say > mvn -Dpgsql.pgconfig=... > java -Dpgconfig=/local/pgsql/bin/pg_config -jar pljava-packaging/... > I had first tried mvn -Dpgconfig, which didn't work - is it really two > different variable names? They are different. Maven has a very large number of named properties, often in prefix.foo form, so I followed that pattern, but the self-install jar has very few. > And is -Dpgconfig even used if for the installer, when > -Dpgconfig.pkglibdir and -Dpgconfig.sharedir are given? I need to > point these to debian/postgresql-$version-pljava/usr/... A "DESTDIR" > mechanism would be nice to have here. I think -Dpgconfig will not be used, if explicit -Dpgconfig.foo values are given for all pljava/foo directory prefixes appearing in the jar. As pkglibdir and sharedir are the only ones I see in the jar, it should be sufficient to explicitly supply those two. > 20:07:07 ERROR: java.lang.ClassNotFoundException: org.postgresql.pljava.example.annotation.ComplexTuple > 20:07:07 CONTEXT: SQL statement "SELECT javatest.assertHasValues( CAST('(1,2)' AS javatest.complextuple), 1, 2)" I believe you'll find this a Heisenbug, and it will go away if you repeat the build and the test. It results from an interaction between the order of commands in the jar's pljava.ddr file and the way PostgreSQL decides when to get an updated snapshot. It will go away if you repeat the build because pljava.ddr is not generated in a fully determined order, but only one that satisfies the annotated provides/requires relationships. Most orderings do not show the problem. :) I had added workarounds already to ComplexScalar and UDTScalarIOTest, but I must have missed ComplexTuple. https://github.com/tada/pljava/blob/V1_5_1b2/pljava-examples/src/main/java/org/postgresql/pljava/exa... https://github.com/tada/pljava/blob/V1_5_1b2/pljava-examples/src/main/java/org/postgresql/pljava/exa... That can be a github issue. I'll work on that before the release. > 20:00:43 [ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.2.3:nar-validate (default-nar-validate) on project pljava-so: NAR: One of two things may be wrong here: > 20:00:43 [ERROR] 1. <Name> tag is missing inside the <Linker> tag of your NAR configuration > 20:00:43 [ERROR] 2. no linker is defined in the aol.properties file for 'ppc64le.Linux.linker' > > Is that a problem in pljava, or a general java-on-that-platform > problem? I think it is probably a Maven-on-that-platform problem. The nar-maven-plugin does not seem to have any toolchain definition for "ppc64le.Linux". As far as ppc, I only see "ppc64.AIX" in its toolchain properties file: https://github.com/maven-nar/nar-maven-plugin/blob/master/src/main/resources/com/github/maven_nar/ao... ("aol" for the nar-maven-plugin means architecture-OS-linker, not an early internet service provider.) PL/Java includes a contributed toolchain properties file for Solaris gcc: https://github.com/tada/pljava/blob/V1_5_1b2/pljava-so/aol.solaris-gcc.properties A similar contributed file for ppc64le.Linux should work. It could be a github pull request. -Chap ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-16 22:12 Chapman Flack <[email protected]> parent: Christoph Berg <[email protected]> 0 siblings, 1 reply; 18+ messages in thread From: Chapman Flack @ 2018-09-16 22:12 UTC (permalink / raw) To: Christoph Berg <[email protected]>; [email protected] On 09/16/18 16:27, Christoph Berg wrote: >> 20:07:07 CONTEXT: SQL statement "SELECT javatest.assertHasValues( CAST('(1,2)' AS javatest.complextuple), 1, 2)" Yup, ComplexTuple again.... > 20:06:38 CONTEXT: SQL statement "SELECT javatest.assertHasValues(CAST('(1,2)' AS point), 1, 2)" Point this time. Sigh. Same issue. Instead of the silly boot functions, I should probably add to PL/Java a way to request a CommandCounterIncrement, and have install_jar always use it, after loading the jar, before running the DDR commands. > Also, does it have to be that verbose all the time, even if things > worked? I don't have very good control yet. There's a page on the wiki for how I *want* the logging to work: https://github.com/tada/pljava/wiki/Thoughts-on-logging ... and I also want, eventually, the testing to happen in a more standard way, such as TAP (tap4j and pgtap). But those goals still need a substantial development effort. For now, I am stuck with one example function that writes verbose log messages, and using INFO for the succeeding ones and WARNING for the failing ones. And even different PostgreSQL versions have different amounts of verbose logging that they do for CREATE TYPE commands, etc. > 20:22:25 Exception in thread "main" java.lang.ClassCastException: sun.org.mozilla.javascript.ConsString cannot be cast to java.lang.String Could you try changing pljava-packaging/build.xml at line 353 from computedPath = replacement + computedPath.slice(plen); to computedPath = new java.lang.String(replacement + computedPath.slice(plen)); I keep being surprised by differences in the JavaScript interpreter supplied in different Java runtimes; the unchanged code has worked without problems on so many. But I *think* this should work on your jdk7 and not break others.... -Chap ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-17 01:30 Chapman Flack <[email protected]> parent: Chapman Flack <[email protected]> 1 sibling, 1 reply; 18+ messages in thread From: Chapman Flack @ 2018-09-17 01:30 UTC (permalink / raw) To: Christoph Berg <[email protected]>; [email protected] On 09/16/18 17:36, Chapman Flack wrote: > The nar-maven-plugin does not seem to have any toolchain definition > for "ppc64le.Linux". As far as ppc, I only see "ppc64.AIX" in its > toolchain properties file: > > https://github.com/maven-nar/nar-maven-plugin/blob/master/src/main/resources/com/github/maven_nar/ao... > > ("aol" for the nar-maven-plugin means architecture-OS-linker, not an early > internet service provider.) > > PL/Java includes a contributed toolchain properties file for Solaris gcc: > https://github.com/tada/pljava/blob/V1_5_1b2/pljava-so/aol.solaris-gcc.properties > > A similar contributed file for ppc64le.Linux should work. It could be > a github pull request. Ideally, such a pull request would add documentation too, like https://github.com/tada/pljava/commit/9a76b4a -Chap ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-17 14:47 Christoph Berg <[email protected]> parent: Chapman Flack <[email protected]> 0 siblings, 1 reply; 18+ messages in thread From: Christoph Berg @ 2018-09-17 14:47 UTC (permalink / raw) To: Chapman Flack <[email protected]>; +Cc: [email protected] Re: Chapman Flack 2018-09-17 <[email protected]> > > 20:22:25 Exception in thread "main" java.lang.ClassCastException: sun.org.mozilla.javascript.ConsString cannot be cast to java.lang.String > > Could you try changing pljava-packaging/build.xml at line 353 from > > computedPath = replacement + computedPath.slice(plen); > > to > > computedPath = new java.lang.String(replacement + computedPath.slice(plen)); That shifted the problem a bit: + java -Dpgsql.pgconfig=/usr/lib/postgresql/9.4/bin/pg_config -Dpgconfig.pkglibdir=debian/postgresql-9.4-pljava/usr/lib/postgresql/9.4/lib -Dpgconfig.sharedir=debian/postgresql-9.4-pljava/usr/share/postgresql/9.4 -jar build-9.4/pljava-pg9.4-amd64-Linux-gpp.jar Exception in thread "main" java.lang.ClassCastException: sun.org.mozilla.javascript.NativeJavaObject cannot be cast to java.lang.String at org.gjt.cuspy.JarX.extract(JarX.java:670) at org.gjt.cuspy.JarX.extract(JarX.java:445) at org.gjt.cuspy.JarX.main(JarX.java:419) > I keep being surprised by differences in the JavaScript interpreter > supplied in different Java runtimes; the unchanged code has worked > without problems on so many. But I *think* this should work on your jdk7 > and not break others.... We could just declare openjdk-8 to be required on the packaging side, that excludes jessie and trusty which will be EOL soonish anyway. Christoph ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-18 01:45 Chapman Flack <[email protected]> parent: Christoph Berg <[email protected]> 0 siblings, 1 reply; 18+ messages in thread From: Chapman Flack @ 2018-09-18 01:45 UTC (permalink / raw) To: Christoph Berg <[email protected]>; [email protected] On 09/17/18 10:47, Christoph Berg wrote: > Re: Chapman Flack 2018-09-17 <[email protected]> >> computedPath = replacement + computedPath.slice(plen); >> to >> computedPath = new java.lang.String(replacement + computedPath.slice(plen)); > > ClassCastException: sun.org.mozilla.javascript.NativeJavaObject cannot be cast to java.lang.String I have no words. :) One more (less intuitive) thing might be worth trying: computedPath = String(replacement + computedPath.slice(plen)); Would you have time to try it that way? I can't make the exception happen here, even with an Oracle jdk7 that is installed. Correction ... I can make it happen (prior to this change) in an icedtea-6 build installed here, with a dubious version of the Rhino-to-JSR223 adapter jar. And the change above to String(...) does seem to fix it (without breaking any of the other versions I can test). I was first guessing the issue would be the change of the bundled JavaScript implementation from Rhino in jdk6/7 to Nashorn in jdk8. But in both cases there is also an adapter layer so that the Java JSR223 API is the same whether Rhino or Nashorn is underneath. And the pre-jdk8 OpenJDK builds seem to have ended up with an older, incomplete version of the Rhino adapter (rhino-js-engine.jar) than what was in the Oracle builds, and it doesn't handle all of the data type conversions as it should. Apparently it will correctly convert a JavaScript String to a Java String. Apparently it does *not* know what to do with a JavaScript wrapper of an actual Java string. :) And it seems Rhino has a clever object, this ConsString, that is an implementation detail of a JavaScript string created efficiently by concatenation, and of course the adapter doesn't know what to do with that either. So using that to construct a brand new ordinary JavaScript String seems to be the one way to get a successful conversion. -Chap ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-18 08:51 Christoph Berg <[email protected]> parent: Chapman Flack <[email protected]> 0 siblings, 0 replies; 18+ messages in thread From: Christoph Berg @ 2018-09-18 08:51 UTC (permalink / raw) To: Chapman Flack <[email protected]>; +Cc: [email protected] Re: Chapman Flack 2018-09-18 <[email protected]> > One more (less intuitive) thing might be worth trying: > > computedPath = String(replacement + computedPath.slice(plen)); That worked, tested on openjdk-7/trusty and openjdk-8/sid. (Now it doesn't pass the "install_jar" test anymore because of java.lang.ClassNotFoundException: org.postgresql.pljava.example.annotation.ComplexTuple...) Submitted as https://github.com/tada/pljava/pull/175 Christoph ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-18 09:21 Christoph Berg <[email protected]> parent: Chapman Flack <[email protected]> 0 siblings, 1 reply; 18+ messages in thread From: Christoph Berg @ 2018-09-18 09:21 UTC (permalink / raw) To: Chapman Flack <[email protected]>; +Cc: [email protected] Re: Chapman Flack 2018-09-17 <[email protected]> > > The nar-maven-plugin does not seem to have any toolchain definition > > for "ppc64le.Linux". As far as ppc, I only see "ppc64.AIX" in its > > toolchain properties file: > > > > https://github.com/maven-nar/nar-maven-plugin/blob/master/src/main/resources/com/github/maven_nar/ao... > > > > ("aol" for the nar-maven-plugin means architecture-OS-linker, not an early > > internet service provider.) :) > > PL/Java includes a contributed toolchain properties file for Solaris gcc: > > https://github.com/tada/pljava/blob/V1_5_1b2/pljava-so/aol.solaris-gcc.properties > > > > A similar contributed file for ppc64le.Linux should work. It could be > > a github pull request. > > Ideally, such a pull request would add documentation too, like > https://github.com/tada/pljava/commit/9a76b4a I got it working: https://salsa.debian.org/postgresql/postgresql-pljava/blob/master/debian/patches/aol-properties It probably makes more sense to have this merged into nar-maven-plugin than to have it live as a wart in pljava. I'll submit a PR there and stick with the patch in the Debian package until there's a nar release that has it. Christoph ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-18 09:29 Christoph Berg <[email protected]> parent: Christoph Berg <[email protected]> 0 siblings, 0 replies; 18+ messages in thread From: Christoph Berg @ 2018-09-18 09:29 UTC (permalink / raw) To: Chapman Flack <[email protected]>; [email protected] Re: To Chapman Flack 2018-09-18 <[email protected]> > It probably makes more sense to have this merged into nar-maven-plugin > than to have it live as a wart in pljava. I'll submit a PR there and > stick with the patch in the Debian package until there's a nar release > that has it. FTR, https://github.com/maven-nar/nar-maven-plugin/pull/328 Christoph ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-09-18 10:46 Christoph Berg <[email protected]> parent: Chapman Flack <[email protected]> 1 sibling, 0 replies; 18+ messages in thread From: Christoph Berg @ 2018-09-18 10:46 UTC (permalink / raw) To: Chapman Flack <[email protected]>; +Cc: [email protected] Re: Chapman Flack 2018-09-16 <[email protected]> > > i.e. it's replacing both occurrences of "i386" by "1". > > Ok, that's irritating. I can guess what is happening. I implement the > -Dpljava.libjvmdefault by passing the string into cpp with a -D, and that > gets converted to a string using the CppAsString2 macro, and that apparently > is not protected from expansion of other macros, and I bet something is > defining i386 to be 1. > > Phooey. > > I don't know if that will be easy to fix using cpp. An alternative would be > to pass it to cpp already quoted according to C rules, but that would be > somewhat ugly to express in a Maven build script. We could try "-Ui386" if there's a way to pass that flag into the build process? Filed at https://github.com/tada/pljava/issues/176, let's continue there. > Your SET command to correct the library name completed the installation > of PL/Java, but at that point it was no longer within a CREATE EXTENSION > command, so the various functions, tables, etc., have just been installed > 'loose' (exactly as they would if you were installing in 9.0 or earlier > with no 'extension' mechanism). Oh, that's unexpected. Wouldn't it be time to unsupport that and move to a "normal" extension .sql script? > > Proceeding to load the examples: > > > Server beendete die Verbindung unerwartet > > Is there anything in the server log with details of the crash? > In many cases there will be a lengthy message from the JVM in the server > log, and that message will contain a file name (something like > /tmp/hs_err_pidnnnn.log) which will contain *even more* detail. > I would be interested to see that. Was this still on i386 ? Filed as https://github.com/tada/pljava/issues/177 with attachment. > > 20:07:07 ERROR: java.lang.ClassNotFoundException: org.postgresql.pljava.example.annotation.ComplexTuple > > 20:07:07 CONTEXT: SQL statement "SELECT javatest.assertHasValues( CAST('(1,2)' AS javatest.complextuple), 1, 2)" > > I believe you'll find this a Heisenbug, and it will go away if you repeat > the build and the test. https://github.com/tada/pljava/issues/178 Christoph ^ permalink raw reply [nested|flat] 18+ messages in thread
* PL/Java 1.5.1_BETA2 @ 2018-10-17 05:49 Chapman Flack <[email protected]> 0 siblings, 2 replies; 18+ messages in thread From: Chapman Flack @ 2018-10-17 05:49 UTC (permalink / raw) To: [email protected]; pgsql-pkg-yum Hello packagers, There is a PL/Java 1.5.1 release at github, supporting PG 11 back to PG 8.2: https://github.com/tada/pljava/releases/tag/V1_5_1 Release notes: http://tada.github.io/pljava/releasenotes.html It requires Java 8 to build; its pljava.libjvm_location GUC can be pointed at run time to any Java 6 to Java 11 (and, with luck, later) JRE. When pointed to a later JRE, it allows a user to write and use Java functions using the latest language features. The build script allows a default value for libjvm_location to be built in. A package built for a platform with a standardized location for Java can build in an appropriate default, so the user experience of installing PL/Java is as simple as possible, and doesn't require setting the GUC first. A reasonable value for the default might be whatever version of Java would be installed by the target distro/release's default-java or similar package. That way, PL/Java could be installed in simple cases without pulling in another JRE if the default one is already there. A site that needs a different Java version could then download that and adjust the GUC accordingly. The PL/Java build instructions are here: http://tada.github.io/pljava/build/build.html ... and a page of tips specifically for packaging is here: http://tada.github.io/pljava/build/package.html I hope this new version can find a home in your repositories. If it gives you any difficulties, please let me know. Thanks! Chapman Flack ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1 (not BETA2, forgot to edit subject) @ 2018-10-17 16:57 Chapman Flack <[email protected]> parent: Chapman Flack <[email protected]> 1 sibling, 0 replies; 18+ messages in thread From: Chapman Flack @ 2018-10-17 16:57 UTC (permalink / raw) To: [email protected]; pgsql-pkg-yum On 10/17/18 01:49, Chapman Flack wrote: > There is a PL/Java 1.5.1 release at github, supporting PG 11 back to PG 8.2: In my haste to announce, I reused an old mail and didn't take the "BETA2" out of the Subject:. I also omitted one detail. The new release has some optionally-built examples, built only if -Psaxon-examples is on the mvn command line. The switch should only be included when building for PG 8.4 or newer, and building with Java 8. When present, it will add the ~ 5 MB Saxon-HE-9.8.0.14.jar at build time (which Maven will automatically fetch, if not constrained to build offline). The jar will not be included in the built package, so it will become an optional run-time dependency. The related examples will still be included in the examples jar, and declared in PostgreSQL if the examples jar is loaded, but the Saxon-HE jar would have to be obtained and installed before they will work. It would be ideal to have the package built that way (whenever the PG version is >= 8.4), so that simply obtaining the Saxon jar will be the only extra step required for anyone interested in trying those examples. Regards, -Chap ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-10-18 10:50 Devrim Gündüz <[email protected]> parent: Chapman Flack <[email protected]> 1 sibling, 1 reply; 18+ messages in thread From: Devrim Gündüz @ 2018-10-18 10:50 UTC (permalink / raw) To: Chapman Flack <[email protected]>; pgsql-pkg-yum Hi Chapman, On Wed, 2018-10-17 at 01:49 -0400, Chapman Flack wrote: > There is a PL/Java 1.5.1 release at github, supporting PG 11 back to PG 8.2: Thanks! Will push the packages in a few hours. Regards, -- Devrim Gündüz EnterpriseDB: https://www.enterprisedb.com PostgreSQL Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR Attachments: [application/pgp-signature] signature.asc (833B, 2-signature.asc) download ^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: PL/Java 1.5.1_BETA2 @ 2018-10-19 00:26 Chapman Flack <[email protected]> parent: Devrim Gündüz <[email protected]> 0 siblings, 0 replies; 18+ messages in thread From: Chapman Flack @ 2018-10-19 00:26 UTC (permalink / raw) To: Devrim Gündüz <[email protected]>; pgsql-pkg-yum On 10/18/18 06:50, Devrim Gündüz wrote: > > Hi Chapman, > > On Wed, 2018-10-17 at 01:49 -0400, Chapman Flack wrote: >> There is a PL/Java 1.5.1 release at github, supporting PG 11 back to PG 8.2: > > Thanks! Will push the packages in a few hours. Thanks! I looked in one of the rpms, and I noticed a few things: 1. It doesn't install these files in share/.../pljava: pljava--1.5.0--1.5.1.sql pljava--1.5.0-BETA1--1.5.1.sql pljava--1.5.0-BETA2--1.5.1.sql pljava--1.5.0-BETA3--1.5.1.sql pljava--1.5.1-BETA1--1.5.1.sql pljava--1.5.1-BETA2--1.5.1.sql pljava--1.5.1-BETA3--1.5.1.sql The build procedure probably tricked you there, because those files don't really exist in the build directory. They are all identical, simply copies of a prototype file pljava--.sql (which does not need to be installed under that name at all), and they just get inserted synthetically into the installer jar as it is built. You are bypassing the installer jar, so they just need to be made somehow. You could make copies or links at build time, or even just include one of them and make the remaining copies/links on the target system in a post-install script. But they have to be there, or ALTER EXTENSION pljava UPDATE won't work. 2. If -Dso.debug=true is added to the mvn command line, there will be debug symbols in libpljava-...so to allow for making a debuginfo rpm. 3. I notice this rpm does not include the pljava-examples...jar. Can there be a separate examples rpm then (or could the jar just be included in the main rpm)? A lot of the older examples are trivial things or tests, but there's a new one in this release that's nontrivial and useful (provides real SQL:2006+ XML Query support, which core PG still doesn't have). Some people might actually have reasons to want to install that one. It is not built unless -Psaxon-examples is on the mvn command line. It is optional because it must be left out when building for PG 8.3 or 8.2. But it is usable in any of the current supported releases. Thanks! -Chap ^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2018-10-19 00:26 UTC | newest] Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2018-09-10 18:04 PL/Java 1.5.1_BETA2 Chapman Flack <[email protected]> 2018-09-15 20:32 ` Christoph Berg <[email protected]> 2018-09-15 21:03 ` Chapman Flack <[email protected]> 2018-09-16 20:18 ` Christoph Berg <[email protected]> 2018-09-16 20:27 ` Christoph Berg <[email protected]> 2018-09-16 22:12 ` Chapman Flack <[email protected]> 2018-09-17 14:47 ` Christoph Berg <[email protected]> 2018-09-18 01:45 ` Chapman Flack <[email protected]> 2018-09-18 08:51 ` Christoph Berg <[email protected]> 2018-09-16 21:36 ` Chapman Flack <[email protected]> 2018-09-17 01:30 ` Chapman Flack <[email protected]> 2018-09-18 09:21 ` Christoph Berg <[email protected]> 2018-09-18 09:29 ` Christoph Berg <[email protected]> 2018-09-18 10:46 ` Christoph Berg <[email protected]> 2018-10-17 05:49 PL/Java 1.5.1_BETA2 Chapman Flack <[email protected]> 2018-10-17 16:57 ` Re: PL/Java 1.5.1 (not BETA2, forgot to edit subject) Chapman Flack <[email protected]> 2018-10-18 10:50 ` Devrim Gündüz <[email protected]> 2018-10-19 00:26 ` Chapman Flack <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox