drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Westin <chriswesti...@gmail.com>
Subject Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Date Wed, 16 Sep 2015 13:17:09 GMT
I only tried to run it from the IDE after it failed in mvn install (in
order to figure out why it's failing). Great, so if it can't work in the
IDE, how do we figure out why it's failing?
On Sep 16, 2015 5:37 AM, "Jacques Nadeau" <jacques@dremio.com> wrote:

> 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