[prev in list] [next in list] [prev in thread] [next in thread]
List: activemq-dev
Subject: [jira] Resolved: (AMQ-1576)
From: "Adrian Co (JIRA)" <jira () apache ! org>
Date: 2008-02-28 3:06:17
Message-ID: 595469426.1204167977831.JavaMail.jira () brutus
[Download RAW message or body]
[ https://issues.apache.org/activemq/browse/AMQ-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]
Adrian Co resolved AMQ-1576.
----------------------------
Fix Version/s: 5.1.0
Resolution: Fixed
> 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
> Fix For: 5.1.0
>
>
> 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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic