Issue with Virtual Schema and JDBC Adapter

harry
Contributor

Hi everyone!

I've been trying to register a virtual schema on an Exasol DB (within a docker container), but it get following error when creating the schema:

F-UDF-CL-LIB-1125: F-UDF-CL-SL-JAVA-1000: F-UDF-CL-SL-JAVA-1037: com.exasol.ExaCompilationException: F-UDF-CL-SL-JAVA-1158: /JDBC_ADAPTER.java:1: error: cannot access com.exasol package com.exasol; ^ zip END header not found

I am using the current docker-latest image (Exasol 7.0 if I am not mistaken). Furthermore, I followed the suggestions on the READMEs of the virtual schemas, that is: I created new bucket and uploaded virtual schema generic JDBC jar and my jdbc driver (also tested that they are correctly uploaded). Then I am running the following commands:

 

CREATE SCHEMA ADAPTER;

CREATE OR REPLACE JAVA ADAPTER SCRIPT ADAPTER.JDBC_ADAPTER AS
%scriptclass com.exasol.adapter.RequestDispatcher;
%jar /buckets/newbucketfs/newbucketfs-bucket/virtual-schema-dist-9.0.3-generic-2.0.0.jar;
%jar /buckets/newbucketfs/newbucketfs-bucket/postgresql-42.2.18.jar;
/

CREATE OR REPLACE CONNECTION GENERIC_CONNECTION
TO 'jdbc:postgresql://myhost:5432'
USER 'usr'
IDENTIFIED BY '***';

CREATE VIRTUAL SCHEMA virt_schema
USING ADAPTER.JDBC_ADAPTER
WITH
CATALOG_NAME = 'db1'
CONNECTION_NAME = 'GENERIC_CONNECTION';

 

I have also tried using the specialized PostgreSQL virtual schema, but I get the exact same error.

Did I forget to run something? Could it be that my docker setup is faulty? Grateful for any hints!

12 REPLIES 12

exa-SebastianB
Team Exasol
Team Exasol

@harry, could you please validate all downloaded JAR files on your machine with the test mode of the zip tool?
https://linux.101hacks.com/archive-compression/validate-zip-file/

If they are clean on your machine, ssh into the docker instance and run the same command there too, to see if they got corrupted by the upload to the container. You can also compare the hash sums on your machine and on the container.
Another thing you should check just in case is if there is enough free space for the container, so that ZIP can be expanded.

View solution in original post

harry
Contributor

Hi @exa-SebastianB. I can't believe it, but this was indeed the problem. The jar files downloaded through curl were broken... Thanks again everyone for your time!

Best,

Harry

exa-SebastianB
Team Exasol
Team Exasol

Don't beat yourself up about it. I learned an important lesson here too. We need to automate adding hash sum files to all of our release artifacts. At the moment we are doing that sporadically, but they should be available next to each distribution file by default.

A simple hash sum comparison would have avoided your whole problem, but for that we need to make sure that we provide those hashes in all cases.

And I just realized that we already have a ticket for that (https://github.com/exasol/release-droid/issues/30) looks like I have to raise the rank on that one.