Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> BadArgumentException in user.VisibilityFilterTest.testFilterUnauthorizedAndBad


+
David Medinets 2013-02-25, 23:23
+
Josh Elser 2013-02-26, 01:12
Copy link to this message
-
Re: BadArgumentException in user.VisibilityFilterTest.testFilterUnauthorizedAndBad
The test in question,
org.apache.accumulo.core.iterators.user.VisibilityFilterTest.testFilterUnauthorizedAndBad
triggers code that logs an error. This is expected behavior, because
we are explicitly exercising code in this test to ensure we survive
this failure case (where a visibility label is corrupted/invalid
grammar).

I'd ignore it... but we might be able to suppress/hide the spam in the
build, if it is bothersome. A third option to those Josh mentioned, is
to use a log4j configuration file specifically for tests that puts
these in a file, rather than STDOUT/STDERR.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Feb 25, 2013 at 8:12 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> Coming from a position where I hate seeing these sorts of things in build
> output, two things are can (easily) address this:
>
> 1) For tests which Exceptions are expected, ensure that loggers aren't going
> to accidentally log it and reset the Log level when the test is done.
>
> 2) Enable redirectTestOutputToFile in the maven surefire plugin so that
> STDOUT is redirected to a file inside of the build temp dir (target).
>
> The latter is an easier fix that tends to be a bit more permanent.
>
> As far as the correctness of the exception being printed, notice
> VisibilityFilterTest#testFilterUnauthorizedAndBad also contains a comment
> "if not explicitly filtering bad labels, they will still be filtered while
> validating against authorizations, but it will be very verbose in the logs",
> which leads me to believe what you're seeing is expected behavior.
>
>
> On 02/25/2013 06:23 PM, David Medinets wrote:
>>
>> I'm not sure if the following exception is expected. It does not cause
>> the build to fail. If it is expected, does it makes sense to add a
>> debug message something like "THE FOLLOWING BadArgumentException IS
>> EXPECTED!"?
>>
>> 13/02/25 18:14:06 ERROR system.VisibilityFilter: Parse Error
>> org.apache.accumulo.core.util.BadArgumentException: empty term near index
>> 0
>> &
>> ^
>>          at
>> org.apache.accumulo.core.security.ColumnVisibility$ColumnVisibilityParser.processTerm(ColumnVisibility.java:240)
>>          at
>> org.apache.accumulo.core.security.ColumnVisibility$ColumnVisibilityParser.parse_(ColumnVisibility.java:253)
>>          at
>> org.apache.accumulo.core.security.ColumnVisibility$ColumnVisibilityParser.parse(ColumnVisibility.java:221)
>>          at
>> org.apache.accumulo.core.security.ColumnVisibility.validate(ColumnVisibility.java:354)
>>          at
>> org.apache.accumulo.core.security.ColumnVisibility.<init>(ColumnVisibility.java:430)
>>          at
>> org.apache.accumulo.core.security.ColumnVisibility.<init>(ColumnVisibility.java:388)
>>          at
>> org.apache.accumulo.core.iterators.system.VisibilityFilter.accept(VisibilityFilter.java:71)
>>          at
>> org.apache.accumulo.core.iterators.user.VisibilityFilter.accept(VisibilityFilter.java:85)
>>          at
>> org.apache.accumulo.core.iterators.Filter.findTop(Filter.java:72)
>>          at org.apache.accumulo.core.iterators.Filter.seek(Filter.java:65)
>>          at
>> org.apache.accumulo.core.iterators.user.VisibilityFilterTest.verify(VisibilityFilterTest.java:85)
>>          at
>> org.apache.accumulo.core.iterators.user.VisibilityFilterTest.testFilterUnauthorizedAndBad(VisibilityFilterTest.java:187)
>>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>          at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>          at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>          at java.lang.reflect.Method.invoke(Method.java:601)
>>          at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>>          at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>          at
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>>          at
+
David Medinets 2013-02-25, 23:31