[
https://issues.apache.org/jira/browse/NIFI-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329820#comment-16329820
]
Mikhail Sosonkin commented on NIFI-4776:
----------------------------------------
I may have jumped the gun on this one :( My apologies! Could have sworn that
asLong() was used in other examples. I looked at the MergeContent processor,
but I looked back and saw that it was using .asDataSize() method.
I guess the issue in this ticket now is a better stack trace for the exceptions
generated during the test run.
> Test suite behavioral differences
> ---------------------------------
>
> Key: NIFI-4776
> URL: https://issues.apache.org/jira/browse/NIFI-4776
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Mikhail Sosonkin
> Priority: Major
>
> I think there might a difference in behavior for how processor attributes are
> evaluated in the test suite vs real execution. I'm not entirely sure if it is
> an expected/acceptable behavior. It has to do with the DATA_SIZE_VALIDATOR.
> Mine was defined as follows:
>
> public static final PropertyDescriptor MAX_ROW_SIZE = new
> PropertyDescriptor
> .Builder().name(BigQueryAttributes.MAX_ROW_SIZE_ATTR)
> .displayName("Max row size")
> .description(BigQueryAttributes.MAX_ROW_SIZE_DESC)
> .required(true)
> .defaultValue("1 MB")
> .addValidator(StandardValidators.DATA_SIZE_VALIDATOR)
> .build();
>
> Then I would use it like this in the onTrigger method:
>
> final long max_row_size = context.getProperty(MAX_ROW_SIZE).asLong();
>
> I used it this way based on the examples I've seen in the other processors.
> In the runtime it seems to be working great and gives me the byte values.
> However, in testing it would throw an exception because it would try to parse
> "1 MB" (the default value) as an actual Long. Of course, if I just place a
> long value (like 1024) it would not pass the validation function. So, I did a
> more explicit "cast" using the asDataSize method:
>
> final long max_row_size =
> context.getProperty(MAX_ROW_SIZE).asDataSize(DataUnit.B).longValue();
>
> This solved my problems and makes the code a bit more explicit which is nice.
> The annoying part is that the StandardProcessorTestRunner does not keep the
> stacktrace from the exceptions generated in onTrigger of the processor
> (StandardProcessorTestRunner:199)
>
> final Throwable thrown = future.get();
>
> That is what caused confusion for me. I hadn't realized that the exception
> was being thrown via my code. So, if anything the test suite needs to do a
> better job at delivering stack traces for the exceptions to help with
> debugging. Depending on what you decide, there might be two tasks here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
