curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: CURATOR-3.0 tests
Date Wed, 25 May 2016 05:37:14 GMT
I have fixed up the test case, all good now.

On Wed, May 25, 2016 at 1:45 PM, Cameron McKenzie <mckenzie.cam@gmail.com>
wrote:

> Looks like it was introduced with the schema validation stuff. It now does
> an ACL check prior to the backgrounding call. Because the unit test uses a
> bogus ACL provider it just throws an exception
>
>         final String adjustedPath =
> adjustPath(client.fixForNamespace(givenPath, createMode.isSequential()));
>         List<ACL> aclList = acling.getAclList(adjustedPath);
>
> client.getSchemaSet().getSchema(givenPath).validateCreate(createMode, data,
> aclList);
>
>         String returnPath = null;
>         if ( backgrounding.inBackground() )
>         {
>             pathInBackground(adjustedPath, data, givenPath);
>
> So, I guess the answer is to get the test to force a failure in a
> different way. With the UnhandledErrorListener, the expectation is that
> this only gets called on backgrounding operations?
> cheers
>
> On Wed, May 25, 2016 at 1:39 PM, Cameron McKenzie <mckenzie.cam@gmail.com>
> wrote:
>
>> Same on the master branch, but it passes there, so maybe something has
>> legitimately broken the test. Will let you know if I get stuck.
>> cheers
>>
>> On Wed, May 25, 2016 at 1:36 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>> Let me know if you need help.
>>>
>>> It might be a bad merge. Have you compared it to the master branch?
>>>
>>> -JZ
>>>
>>> > On May 24, 2016, at 10:31 PM, Cameron McKenzie <mckenzie.cam@gmail.com>
>>> wrote:
>>> >
>>> > Guys,
>>> > There's a test TestFrameworkBackground:testErrorListener that is
>>> failing
>>> > consistently on the CURATOR-3.0 branch.
>>> >
>>> > I can't see how it has ever worked. It seems to try and provoke an
>>> error
>>> > via a bad ACL provider.
>>> >
>>> > But this ACL provider is called by the CreateBuilderImpl prior to the
>>> > backgrounding call, which means that the exception that it throws
>>> happens
>>> > in the main Thread of the unit test. So, it just throws an
>>> > UnsupportedOperationException which is propogated up the stack at which
>>> > point the unit test fails.
>>> >
>>> > So, I will look at fixing this, but I just don't understand how it ever
>>> > worked?
>>> > cheers
>>>
>>>
>>
>

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