[jira] [Updated] (NIFI-2790) Set JMS destination name on send/receive instead of using the default destination

2016-10-07 Thread Michael Moser (JIRA)

 [ 
https://issues.apache.org/jira/browse/NIFI-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Moser updated NIFI-2790:

Fix Version/s: (was: 0.8.0)
   0.7.1

> Set JMS destination name on send/receive instead of using the default 
> destination
> -
>
> Key: NIFI-2790
> URL: https://issues.apache.org/jira/browse/NIFI-2790
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joey Frazee
>Assignee: Joey Frazee
>Priority: Minor
> Fix For: 1.1.0, 0.7.1
>
>
> ConsumeJMS and PublishJMS currently pull their destination name from the 
> default JMS destination (setDefaultDestinationName() on the JmsTemplate). The 
> effect this has is that attribute expressions are evaluated with respect to 
> the context only and not the FlowFile, so expression language support really 
> only extends to EL functions and variables from the variable registry.
> This doesn't have a big impact on ConsumeJMS since it doesn't take input, but 
> it means that destinations can be set at runtime in PublishJMS.
> The JmsTemplate send() and receive() can take the destination name as an 
> argument though, so these method variants should be used so EL support is 
> fully enabled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (NIFI-2790) Set JMS destination name on send/receive instead of using the default destination

2016-09-20 Thread Oleg Zhurakousky (JIRA)

 [ 
https://issues.apache.org/jira/browse/NIFI-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-2790:
---
Fix Version/s: 0.8.0

> Set JMS destination name on send/receive instead of using the default 
> destination
> -
>
> Key: NIFI-2790
> URL: https://issues.apache.org/jira/browse/NIFI-2790
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joey Frazee
>Assignee: Joey Frazee
>Priority: Minor
> Fix For: 1.1.0, 0.8.0
>
>
> ConsumeJMS and PublishJMS currently pull their destination name from the 
> default JMS destination (setDefaultDestinationName() on the JmsTemplate). The 
> effect this has is that attribute expressions are evaluated with respect to 
> the context only and not the FlowFile, so expression language support really 
> only extends to EL functions and variables from the variable registry.
> This doesn't have a big impact on ConsumeJMS since it doesn't take input, but 
> it means that destinations can be set at runtime in PublishJMS.
> The JmsTemplate send() and receive() can take the destination name as an 
> argument though, so these method variants should be used so EL support is 
> fully enabled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (NIFI-2790) Set JMS destination name on send/receive instead of using the default destination

2016-09-19 Thread Oleg Zhurakousky (JIRA)

 [ 
https://issues.apache.org/jira/browse/NIFI-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-2790:
---
Fix Version/s: 1.1.0

> Set JMS destination name on send/receive instead of using the default 
> destination
> -
>
> Key: NIFI-2790
> URL: https://issues.apache.org/jira/browse/NIFI-2790
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joey Frazee
>Assignee: Oleg Zhurakousky
>Priority: Minor
> Fix For: 1.1.0
>
>
> ConsumeJMS and PublishJMS currently pull their destination name from the 
> default JMS destination (setDefaultDestinationName() on the JmsTemplate). The 
> effect this has is that attribute expressions are evaluated with respect to 
> the context only and not the FlowFile, so expression language support really 
> only extends to EL functions and variables from the variable registry.
> This doesn't have a big impact on ConsumeJMS since it doesn't take input, but 
> it means that destinations can be set at runtime in PublishJMS.
> The JmsTemplate send() and receive() can take the destination name as an 
> argument though, so these method variants should be used so EL support is 
> fully enabled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)