Glad you found a solution — and many thanks for sharing it on this list; it will help anyone who runs into the same problem.
> On Nov 2, 2017, at 8:42 AM, [email protected] wrote: > > Sorry for yet another mail in my minor case. > > Just to inform You that my assumptions where correct. Meta created from > Driver based on CalciteConnection is not compatible with LocalService > needed for avatica. After switching to JDBCMeta implementation from the > avatica internal test project - I've managed to connect with squirrel. > > Wow :) > > > Again - thank you for calcite > P > > On Thu, Nov 2, 2017 at 2:32 PM [email protected] <[email protected]> > wrote: > >> Hello Julian, >> >> I am pretty sure that this is not an container issue, ie classloader etc. >> Error stack is eated by avatica AbstractHandler implementation, thus no >> stack presented in SO. But I've attached the code with the suspected issue >> - org.apache.calcite.avatica.Meta.Frame.toProto method. >> >> Mentioned method handles only arrays and iterables but not >> MetaImpl$MetaTableType which is placed under Meta.rows property. This is >> why I rather believe that I've bootstrap calcite with avatica incorrectly >> itself, despite the container used. >> >> For handling the protobuf RCPs I've used following stack: >> >> 1. custom servlet >> 2. org.apache.calcite.avatica.remote.ProtobufHandler - for handling >> requests >> 3. org.apache.calcite.avatica.remote.LocalService under the handler >> 4. DRIVER.createMeta((AvaticaConnection) connection) - as a Meta for >> LocalService >> 5. CalciteConnection - for Meta >> 6. connection created as from examples from calcite site from inline >> JSON >> >> My assumption is that somewhere in this stack exists some incompatibility, >> ie Meta created from Driver from CalciteConnection is not compatible with >> LocalService needed for ProtobufHandler. >> >> Regads and keep up good work - calcite is so advanced library :) >> >> Peter >> >> On Tue, Oct 31, 2017 at 4:33 PM Julian Hyde <[email protected]> wrote: >> >>> The SO question doesn’t have an error stack but I recall seeing previous >>> versions of this question where there were what looked like class-loader >>> issues - class-not-found or similar. I know you’re struggling here, but I’m >>> afraid don’t have time to try to set up your environment to try to >>> reproduce those issues. I do know that these classes work together just >>> fine in the environment we use for testing. Obviously this is a simpler >>> environment, and not useful to you (though not that simple - I recall that >>> Avatica has tests that use jetty). A next step for you might be to start >>> with one of these simple environments and add complexity until something >>> breaks; then you’ll know where the conflict is coming from. >>> >>> Julian >>> >>> >>> >>>> On Oct 31, 2017, at 6:56 AM, [email protected] wrote: >>>> >>>> Hello, >>>> >>>> My task is to expose calcite-made schema through avatica. I've >>> encountered >>>> some stopper here. Some details I've placed at stackoverflow - but no >>> help >>>> there. >>>> >>>> >>> https://stackoverflow.com/questions/46792353/expose-calcite-based-db-through-avatica-by-custom-servlet >>>> >>>> Could you, please, make some hints on where could I made a mistake in my >>>> thinking on the problem? >>>> >>>> Thanks in advance for help! >>>> >>>> Piotr Bojko >>> >>>
