[
https://issues.apache.org/activemq/browse/AMQ-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41335#action_41335
]
Adrian Co commented on AMQ-1576:
--------------------------------
I've added a fix for rev. 629060
The behavior would be that if a jms property is encountered with a null value,
it will not be converted to the ActiveMQ property, but will still be maintained
in the list of jms properties. Let me know if this behavior works for you.
> ActiveMQMessageTransformation.copyProperties NullPointerException
> -----------------------------------------------------------------
>
> Key: AMQ-1576
> URL: https://issues.apache.org/activemq/browse/AMQ-1576
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.0.0
> Environment: running on Fedora Core 6, hitting Oracle 10g for
> persistant storage
> Reporter: Voytek Jarnot
> Assignee: Adrian Co
>
> org.apache.activemq.ActiveMQMessageTransformation copyProperties method
> doesn't check for null before calling setObjectProperty(...)
> This causes null pointer exceptions when trying to bridge Oracle's AQ with
> ActiveMQ - Oracle returns a value of null for JMSXGroupSeq (and maybe others,
> that's the first one that causes the failure).
> Since passing a null to setObjectProperty appears to inevitably fail (null
> pointer thrown from TypeConversionSupport.convert(...)) why not check for
> null and not call setObjectProperty?
> TypeConversionSupport even has an assert line that seems to indicate the
> value should never be null, but calling code (ActiveMQMessageTransformation
> in my case) doesn't prevent that from happening.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
