[Pljava-dev] Windows 64bit officially released

On Wed, 04 May 2011 16:40:55 -0000, Eric Kolotyluk
<eric.kolotyluk at gmail.com> wrote:

> Comments on installation notes:
>
> In general the documentation package in the release itself is terribly
> confusing because much of it is based on 1.2, but that issue goes beyond
> your notes.
>
> 1. Tell people the postgresql.conf file is in the data directory.
> It's not obvious and I had to search a half a dozen documents
> before I found that little gem of wisdom.

Right. It's been updated. Is that clear enough?

> 2. The part about using org.postgresql.pljava.deploy.Deployer is
> confusing. It would read better as
>
> You can also use the deployer program to do the installation. For
> instructions just run
>
> java -jar deployer.jar

If that had worked for me, I would. See below.

> 3. Also, when I actually tried to install using the deployer I got
>
> java.lang.ClassNotFoundException: org.postgresql.Driver
> at java.net.URLClassLoader$1.run(Unknown Source)
[snip]
> at
> org.postgresql.pljava.deploy.Deployer.main(Deployer.java:238)
>
> which begs the question, where does org.postgresql.Driver come
> from? If you wanted to be really kind to your users then
> deploy.jar would be an uber-jar with everything it needs to run.

The org.postgresql.Driver comes from JDBC, postgresql-9.0-801.jdbc4.jar
available here,

http://jdbc.postgresql.org/

I got it to work by placing both jars on the classpath and then run it
as described in the notes. I've now added this information into the
installation notes.

I'm not sure it's very smart to include it in the PL/Java distribution
(the deploy.jar) - it has a life of its own.

> 4. Is putting the JRE on the PATH the only way to configure this?
> Some people have an embedded JRE in their application, and it is
> not suitable to put it on the PATH. What component actually
> invokes the JRE (the pljava.dll or something else), and can it be
> configured more directly with a specific locations for jre/bin,
> jre/bin/clinet or jre/bin/server?

It is pljava.dll that invokes and loads jvm.dll. It is straight forward
to configure specific Java VM for pljava on Unix. That's what Feature
Request 1010955 is all about.

http://pgfoundry.org/tracker/index.php?func=detail&aid=1010955&group_id=1000038&atid=337

The description doesn't explain anything to those who do not know what
LD_LIBRARY_PATH is though.

On Windows, I do not know what controls the DLL search path other than
the system path itself. The problem is really my lack of Windows know-
ledge. On Solaris (and possibly Linux) I can say "look for jvm.dll in
this directory relevant to the location of the file that's loading it."
So it doesn't matter where you place pljava.dll, (On Unix it's actually
called pljava.so, and jvm.dll is libjvm.so but that's irrelevant to the
discussion), it can always find the jvm.dll that's distributed with the
package.

My question for Windows experts would be:

1) What are per-process controls for DLL search paths?

2) Can DLL search paths been built into DLLs, EXEs?

3) If 2) can they be made relative to the location of the corresponding
DLL or EXE?

> Otherwise the instructions are fairly straightforward for installing
> PLJava. I wish the same could be said for using it.

Yes, that's my next real priority for PL/Java, to update the document-
ation.

--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/