Hey Christian,
Definitely something concrete that we can poke at would help. Your
approach is how I intend it to work (granted, I need to step back and
think about the big picture from Calcite instead of just Avatica).
If you can publish your project and provide some steps to run it, that
would be a huge help in figuring out why things aren't working as intended.
Christian Tzolov wrote:
Thanks for the reference Gethin!
Although CALCITE-1461
<https://issues.apache.org/jira/browse/CALCITE-1461> seems
related, IMO the issue is different.
I am using an up to date 1.11.0 codebase (that contains the 1461 patch).
The problem occurs while trying to create the jenino CompileFactory, before
the ClassDeclaration is being used.
As an attempt to bypass the "org.codehaus.commons.compiler.properties" I've
tried to replace the "compilerFactory =
CompilerFactoryFactory.getDefaultCompilerFactory();" by "compilerFactory
=
CompilerFactoryFactory.getCompilerFactory("org.codehaus.janino.CompilerFactory");"
Still the problem remains. The CompilerFactory class cannot be found by the
Thread.currentThread().getContextClassLoader(). The
"org.codehaus.janino.CompilerFactory" class is present in the Uber JDBC jar
but for some reasons the thread context can not reach it.
May be it is time to open a JIRA ticket and continue the discussion there.
Just need to find a proper way to reproduce it.
Cheers,
Christian
On 21 November 2016 at 09:33, Gethin James<[email protected]>
wrote:
Have you had a look at https://issues.apache.org/jira/browse/CALCITE-1461
? The fix version is 1.11.0.
Best regards,
Gethin.
________________________________
From: Christian Tzolov<[email protected]>
Sent: 21 November 2016 09:23:51
To: [email protected]
Subject: Re: Calcite jdbc driver dependencies
Further digging suggests that the root cause of the problem is Janino not
being able to resolve its 'org.codehaus.commons.compiler.properties' from
the class path.
The input stream is resolved to null in the
CompilerFactoryFactory#getDefaultCompilerFactory:
'InputStream is =
Thread.currentThread().getContextClassLoader().getResourceAsStream("org.
codehaus.commons.compiler.properties");'
The is is null although the 'org.codehaus.commons.compiler.properties' is
available at the root for the uber jdbc jar. Apparently the
Thread.currentThread().getContextClassLoader() is relative to something
else but the root classpath.
Any suggestions will be appreciated :) I've noticed similar issues reported
on the Phoenix project.
Cheers,
Christian
On 21 November 2016 at 00:44, Christian Tzolov<[email protected]> wrote:
The underlying exception causing the "Unable to instantiate java
compiler" seems
to be:
*Caused by: java.lang.ClassNotFoundException: No implementation of
org.codehaus.commons.compiler is on the class path. Typically, you'd have
'janino.jar', or 'commons-compiler-jdk.jar', or both on the classpath.*
* at
org.codehaus.commons.compiler.CompilerFactoryFactory.
getDefaultCompilerFactory(CompilerFactoryFactory.java:59)*
* at
org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.compile(
JaninoRelMetadataProvider.java:425)*
I've tried to manually add the 'janino.jar' and
'commons-compiler-jdk.jar'
jars as well as excluding them from the uber jdbc jar. But the error is
still there
On 21 November 2016 at 00:18, Christian Tzolov<[email protected]>
wrote:
The uberized jdbc adapter fails with "Unable to instantiate java
compiler" when i try it with tools like DbVisualizer or SQurriel .
Noticed same error has been discussed in two others thread but there is
no resolution. In my case the adapter pom contains a single janino-2.7.6
dependency (via the calcite-core).
Could this be related to the maven-shade-plugin configuration?
On 20 November 2016 at 23:52, Christian Tzolov<[email protected]>
wrote:
FYI, the uber jar jdbc did the job
On 20 November 2016 at 22:34, Christian Tzolov<[email protected]>
wrote:
Hi,
I've been working on Calcite adapter for a nosql datastore.
The prototype works fine when i test it with the Sqlline command line
tool. But it is not entirely clear how to use it through a jdbc
driver from
3rd party tools. I've read the avatica docs but not sure if i'm
getting it
right.
For the loca jdbc driver case do i need build my adapter as an uber
jar
to bundle all necessary dependencies? If so are there any examples
around?
For the remote jdbc mode do i need to create and build a customer
avatica server that pulls my adapters dependencies?
I am sorry if this question has been answered already
Cheers,
Christian
