[postgis-devel] [Fwd: postgis failure on debian woody]

[Markus Schaber]

Hi, Alex,

alexbodn at 012.net.il schrieb:

> we should realy turn the discussion to postgis-devel.
> 
> as you say, java/sql/Statement.getResultSetConcurrency is expected to
>  be  a jvm method, not a postgresql jdbc one.

Not exactly the jvm, it should be part of the standard library. Most VMs
can be ran with different standard library implementations, e. G. gij
can use both libgcj and GNU classpath.

> i might be wrong, but i understand that methods existance is not 
> being required at compile time, thus permitting linking with any 
> library. this is like in c/c++, but there the methods should be at 
> least declared at compile time.

The method must be present at compile time. Otherwise, the compiler
refuses to compile the code that links against it.

Theoretically, you can implement the method and manually throw the
Java.lang.NoSuchMethodError exception from inside your implementation.
But lets look at the stacktrace:

java.lang.NoSuchMethodError:java/sql/Statement.getResultSetConcurrency()I
	at org.postgresql.jdbc2.Connection.getResultSet(source file
unknown:line unknown, pc 0x82cfc0e)
	at org.postgresql.core.QueryExecutor.execute(source file unknown:line
unknown, pc 0x82ca86e)

At least my reading of this stacktrace is that the Exception complaining
about the missing getResultSetConcurrency() is thrown inside of
getResultSet(). So I think that the method getResultSetConcurrency() of
class Statement is not implemented, and the JVM uses so-called late
binding, thus the Error is thrown on the first try to actually call this
method (as opposed to Program start time when using early binding).

> both postgis jars are being completely made with either jikes/kaffe 
> or jikes/gcj, as distributed with woody. making the tests target 
> require implementation of certain methods in the runtime library, 
> that are missing from the kaffe jvm.

Not only making the test targets, but using postgres.jar in general, as
far as I understand the problem.

> i will also try jvm from sun and ibm, although those are not free. 
> but users are free, so we should provide a quality product.

You can also try to use another one of the standard libraries, e. G. libgcj.

>> Maybe the debian pgjdbc and java maintainers are the better ones to
>>  help here.
> you are right, especially if i will find a reference to the called 
> methods in the sources of postgresql.jar and it's testing procedures.
> 
> 
You can also send them the version printing program as an example. It
should work without any exception against a plain postgresql server, and
simply report all postgis versions as "unavailable".

>> Why do you rename this variable here? CLASSPATH is the standard 
>> environment variable that is set on all Java environments I know.
> defining CLASSPATH, as well as invoking with -classpath (as oposed to
>  -addclasspath), is setting the whole classpath. again, this might 
> not be that important for compilation, but is cardinal for the 
> linking phase, where the core jvm classes are been needed. in every 
> java/djavac invocation you are passing with -classpath a string 
> containing the one you have previously set CLASSPATH to. thus, 
> variable CLASSPATH is redundant anyway, but i ask you to remove it, 
> since it is destroying the jvm classpath.

Then the jvm is broken. JVMs have to distinguish between what you give
via the -classpath or $CLASSPATH and their system class path (also known
as bootclasspath, which can be set via another command line option, and
has to point to a sane default). This concept makes it possible to run
different JVMs with their respective bootclasspathes under the same
CLASSPATH environment variable that points to all the non-system jars
(like postgis, postgresql and whatever) that are shared between all JVMs.

As I wrote you earlier, the workaround for your environment is to make
CLASSPATH point to both the postgresql.jar and your jvm system library
before calling the Makefile.

>>> -	$(JAR) -uf postgis_debug.jar -C $(SRCDIR) . +	$(JAR) -cf 
>>> postgis_debug.jar -C $(BUILD) . -C . README
>> 
>> COPYING_LGPL -C .. COPYING \
>> 
>>> +	-C $(SRCDIR) .
>> 
> this seems to be the most heavy issue: both fastjar and jar from 
> kaffe fail on -uf. the most elegant solution i see is having targets
>  jar_debug and jar_debug_old, and have jar depend on $(JAR_DEBUG). 
> just set JAR_DEBUG ?= jar_debug, so an user might consciously set it
>  to jar_debug_old.

Seems pretty ugly for me. We could also "cp -a" everything together into
one directory tree before creating the jar. But this is ugly, too. I'll
see what I can do...

>>> test:	compile -	$(JAVA) -classpath "$(BUILD):$(CP)" 
>>> $(EXAMPLES)/Test +	$(JAVA) -addclasspath "$(BUILD):$(CP)" 
>>> $(EXAMPLES)/Test
>> non standard argument. I'll see what we can do to cope with this, 
>> but there must be a better option.
> the solution is not that hard: you might make a variable like 
> ADDCP_ARG ?= -classpath. users change it in the env for their 
> interpreters.

IMHO, the solution is to set the CLASSPATH environment variable correctly.

>>> -PGUSER?=psql +PGUSER?=pgres
> i appologize, i shouldn't have posted this to you.

No problem,
Markus

-- 
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios at logi-track.com | www.logi-track.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20050222/f47a2c81/attachment.sig>