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

[Markus Schaber]

Hi, Alex,

Please keep the discussion on postgis-devel, so we have more eyes
looking on what we do.

Von: alex bodnaru <alexbodn at 012.net.il>

> i have done the test you sent me. result attached.

See below.

> as i see, the c code patches have already been applied. thans.

It is strk who deserves this thanks.

> attached here is newer versions patch, including a few jdbc2 specific
> ones.

Thanks. I committed parts of those jdbc2 stuff, but some things IMHO
still need discussion, see below.

> java -addclasspath "bin:/usr/share/java/postgresql.jar:src/" examples/VersionPrinter jdbc:postgresql://localhost:5432/jdbc_test postgres guess
> ** PostGIS jdbc client code **
> 	getFullVersion: PostGIS JDBC V1.0.0RC3
> 
> ** PGJDBC Driver **
> 	getVersion: PostgreSQL 7.2 JDBC2
> 	getMajorVersion: 7
> 	getMinorVersion: 2
> 
> ** PostgreSQL Server **
> 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 org.postgresql.Connection.ExecSQL(source file unknown:line unknown, pc 0x82ae700)
> 	at org.postgresql.jdbc2.Statement.execute(source file unknown:line unknown, pc 0x83160ea)
> 	at org.postgresql.jdbc2.Statement.executeQuery(source file unknown:line unknown, pc 0x8306de2)
> 	at examples.VersionPrinter.getVersionString(VersionPrinter.java:125)
> 	at examples.VersionPrinter.printVersionString(VersionPrinter.java:120)
> 	at examples.VersionPrinter.main(VersionPrinter.java:92)

This clearly indicates that basic jdbc functionality is not working. I
think that the java.sql.Statement implementation of your JVM or class
library does not fit together with what postgresql.jar expects.

The reason may be that this method is simply not implemented in the
class library. Another possibility is that your postgresql.jar is
compiled for a different JDBC version compared to what your java
environment compiles.

Could you try different class libraries? I think the best way is to find
out which one was used to compile the postgresql.jar against. There, the
method is present, because the compilation was successful.

Maybe the debian pgjdbc and java maintainers are the better ones to help
here.

> diff -ur -x debian postgis-cvs4.orig/jdbc2/Makefile postgis-cvs4/jdbc2/Makefile
[...]
> -CLASSPATH?=/usr/share/java/postgresql.jar
> -CP=$(CLASSPATH):src/
> +PG_CLASSPATH?=/usr/share/java/postgresql.jar
> +CP=$(PG_CLASSPATH):src/

Why do you rename this variable here? CLASSPATH is the standard
environment variable that is set on all Java environments I know.

> -PGUSER?=psql
> +PGUSER?=pgres
>  PGPASS?=guess

Is pgres a default user that exists on woody?

>  postgis_debug.jar: compile $(SRC) $(SRCDIR)/org/postgresql/driverconfig.properties
> -	$(JAR) -cf postgis_debug.jar -C $(BUILD) . README COPYING_LGPL -C .. COPYING
> -	$(JAR) -uf postgis_debug.jar -C $(SRCDIR) .
> +	$(JAR) -cf postgis_debug.jar -C $(BUILD) . -C . README COPYING_LGPL -C .. COPYING \
> +	-C $(SRCDIR) .

This one does not work with some jar implementations (especially the SUN
ones), -cf fails if it comes across a subdirectory name that was already
used before. Both $(BUILD) and $(SRCDIR) contain an org/ subdirectory. I
made this mistake myself (using fastjar), strk then had build failures.
That was the reason why we introduced the -uf one.

>  test:	compile
> -	$(JAVA) -classpath "$(BUILD):$(CP)" $(EXAMPLES)/Test
> +	$(JAVA) -addclasspath "$(BUILD):$(CP)" $(EXAMPLES)/Test

I will not accept a change that breaks at least 4 JVMs (SUN, IBM, gij
and sablevm) because it replaces a standard argument with a non-standard
argument. I'll see what we can do to cope with this, but there must be a
better option.

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