[ 
https://issues.apache.org/jira/browse/CAMEL-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465662#comment-15465662
 ] 

ASF GitHub Bot commented on CAMEL-10291:
----------------------------------------

GitHub user gessnerfl opened a pull request:

    https://github.com/apache/camel/pull/1158

    CAMEL-10291: support java.util.date for timestamps in rabbitmq messages

    

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/gessnerfl/camel CAMEL-10291_message_timestamp

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/camel/pull/1158.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1158
    
----
commit 65d372f587aa79479753068533fd8b4aa52671ec
Author: Florian Gessner <[email protected]>
Date:   2016-09-05T19:38:08Z

    CAMEL-10291: support java.util.date for timestamps in rabbitmq messages

----


> Camel RabbitMQ invalid handling of message timestamp
> ----------------------------------------------------
>
>                 Key: CAMEL-10291
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10291
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-rabbitmq
>    Affects Versions: 2.17.3
>            Reporter: Florian Gessner
>            Assignee: Andrea Cosentino
>              Labels: github-pullrequest, patch
>             Fix For: 2.18.0
>
>
> At the moment the RabbitMQ component is does not map the timestamp of a 
> message appropriately. The outbound mapping (producer) expects the timestamp 
> of the camel message is of type String whereas the String is just the long 
> value representing the timestamp. However the timestamp is already a 
> java.util.Date when the producer just forwards a message from a rabbitmq 
> consumer as the timestamp is already a java.util.date as define in 
> AMQP.BasicProperties.
> The provided pull request provides a compatible change. So it still keeps the 
> old behaviour as fallback so that the long value is evaluated if the provided 
> data is not a java.util.Date



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

Reply via email to