Andre, "This design choice seems to trigger" -- I don't think this is a design choice but rather, a bug :)
The Property Descriptor should indicate that Expression Language is supported. The mock framework is setup to fail the unit test because the processor's behavior does not match its documentation (i.e., it does in fact evaluate the Expression Language, but its property descriptor says that it does not). So I believe the fix is to simply update the Property Descriptor to indicate that it does in fact support Expression Language. Thanks -Mark > On Feb 6, 2017, at 8:08 AM, Andre <[email protected]> wrote: > > devs, > > > As part of NIFI-940 I am crafting test coverage for the PutFTP processor. > Upon testing I noticed the following discrepancy: > > The port property lacks Expression Language Support > > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/util/FTPTransfer.java#L71 > > while client.connect seems to evaluate the property. > > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/util/FTPTransfer.java#L531 > > This design choice seems to trigger > > java.lang.IllegalStateException: Attempting to Evaluate Expressions but > PropertyDescriptor[Username] indicates that the Expression Language is not > supported. If you realize that this is the case and do not want this error > to occur, it can be disabled by calling > TestRunner.setValidateExpressionUsage(false) > > > Is this normal? > > Reading the code I suspect the reason for that is the intention to allow > flowfiles to contain the username, password and port attributes and > dynamically route them, but if that's the case, shouldn't we simply mark > the affected properties as supporting expression language? > > Cheers
