drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <jacq...@dremio.com>
Subject Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Date Wed, 16 Sep 2015 12:37:43 GMT
Ah, you're focused on testing from within the IDE?

The level complexity of the build process to get a test to correctly test
the right thing means jumping through a bunch of hoops to clear the
classpath and then use a special classloader. I can't imagine that you
could get it to run correctly in an ide. For example, Eclipse is very
sloppy about keeping classpaths perfect versus what is declared in the pom
file.

The parameter you're looking for is generated by the ant plugin simply
because that appears the way to get the value into an environment variable
so that the inner classloader can load the drillbit for the test.

The test: loads a drillbit in one classloader using the alternative
classpath provided by the app.class.path variable. This is taken from what
would have typically been the jvm level classpath. We then clear the jvm
classpath to only include the test class, Junit and  hamcrest. After the
drillbit is initialized and we've run one query,  we then add the jdbc all
jar to the system classloader and open a connection to the drillbit and
execute a query. The test is designed specifically to confirm that the
requisite classes are correctly included in jdbc-all and that it will run
correctly. The test can't run without the shaded jar being generated and I
can't imagine any of the of the ides have good enough understanding of the
various maven plugins and options used that they would correctly work. Even
if you found some changes that made the test execute in and ide, I can't
imagine that it would correctly manage all the classpath stuff.
On Sep 15, 2015 9:37 PM, "Chris Westin" <chriswestin42@gmail.com> wrote:

> Variability: for me so far 2 out of 2 times.
>
> No stack trace, but as above, when I try to reproduce it in an IDE
> "This seems to be because the test is getting an ExceptionInInitializer in
> DrillbitClassLoader because the app.class.path property isn't set (and then
> the resulting String.length() on its value throws an NPE)."
>
> I don't see app.class.path set anywhere in any pom.xml (so it's not getting
> set when I copy the surefire arguments into the IDE's launch configuration
> for the test, either).
>
>
> On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <jacques@dremio.com>
> wrote:
>
> > It was tested on a clean machine a number of times. Any thoughts on the
> > variability? Can you provide stack trace?
> > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <skatkam@maprtech.com> wrote:
> >
> > > Yes, I see this issue too.
> > >
> > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <chriswestin42@gmail.com>
> > > wrote:
> > > >
> > > > This seems to be because the test is getting an
> ExceptionInInitializer
> > in
> > > > DrillbitClassLoader because the app.class.path property isn't set
> (and
> > > then
> > > > the resulting String.length() on its value throws an NPE).
> > > >
> > > > Bueller?
> > > >
> > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
> chriswestin42@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> I just rebased, and twice in a row I've gotten wedged running
> > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message