[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