[
https://issues.apache.org/jira/browse/NIFI-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215106#comment-15215106
]
ASF GitHub Bot commented on NIFI-1686:
--------------------------------------
Github user steveyh25 commented on the pull request:
https://github.com/apache/nifi/pull/305#issuecomment-202630454
@olegz,
Please see latest commit. The try-catch block has been removed and I've
changed the validation slightly like was spoken about. It appears as though we
don't need to worry about NPE, because if no value is provided for the flow
attribute then it appears to be ignored anyway (i.e it is not a part of
flowFile.getAttributes()).
I couldn't find any great way of dealing with the parsing of values other
than catching the NumberFormatException - things like StringUtils.isNumeric()
are nice but we can still be in a situation where a number is deemed to be
numeric but parseInt will throw an exception anyway because the number's too
big to store - I hope this solution is ok, unless there is a specific way of
validating this that you would like?
I've made specific warnings occur if a property fails validation, including
out of range values.
Let me know what you think,
Thanks
> NiFi is unable to populate over 1/4 of AMQP properties from flow properties
> ---------------------------------------------------------------------------
>
> Key: NIFI-1686
> URL: https://issues.apache.org/jira/browse/NIFI-1686
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 0.5.1
> Reporter: Stephen Harper
>
> When creating a flow (we used ListenHTTP, but this bug will affect all) that
> forwards on to a rabbit queue, org.apache.nifi.amqp.processors.PublishAMQP
> uses the method extractAmqpPropertiesFromFlowFile to populate the AMQP
> BasicProperties if the flow attributes match a certain format (i.e
> amqp$contentType=text/xml).
> The method in question uses reflection to find a matching method name from
> the AMQP.BasicProperties class, and tries to populate accordingly.
> This works fine for all properties that take a String argument - however
> there are some that don't (specifically, headers takes a Map<String, Object>,
> deliveryMode and priority take Integer, and timestamp takes a Date), and it
> is impossible to populate these values because the invocation assumes a
> String is required, and fails on line 210.
> Whatsmore, the comment underneath (line 215) states that "this should really
> never happen since it should be caught by the above IF" - however the author
> of the code mustn't have tested all cases because this error is consistently
> present when trying to forward flow attributes in over a quarter of the
> available amqp properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
