Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <12815039.post@talk.nabble.com>
Date: Fri, 21 Sep 2007 04:45:09 -0700 (PDT)
From: Motl <motl@orcsoftware.com>
To: users@activemq.apache.org
Subject: Re: BytesMessage constness
In-Reply-To: <8a6feb940709210313l21848e68ma988567e0898328c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <12813490.post@talk.nabble.com>
 <8a6feb940709210313l21848e68ma988567e0898328c@mail.gmail.com>


Done.

https://issues.apache.org/activemq/browse/AMQCPP-143


nmittler wrote:
> 
> I agree, this definitely would be a pain since the onMessage method gives
> you a const Message.  Could you capture this issue in JIRA?
> http://issues.apache.org/activemq/browse/AMQCPP
> 
> Thanks,
> Nate
> 
> 
> On 9/21/07, Motl <motl@orcsoftware.com> wrote:
>>
>>
>> Hi,
>> I once asked you why readBytes() and other read methods aren't const:
>>
>> http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672
>>
>> But if only the stream pointer is updated, I suppose we could have
>> another
>> solution here, i.e.
>> declare inputStream field as 'mutable':
>>
>> mutable io::ByteArrayInputStream inputStream;
>>
>> In that case we could keep read methods const.
>>
>> I am requesting for that because at the moment such non-const API forces
>> app
>> level either always deal with non-const objects or make
>> const_cast<cms::BytesMessage *>(), that's not good.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/BytesMessage-constness-tf4492790s2354.html#a12813490
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/BytesMessage-constness-tf4492790s2354.html#a12815039
Sent from the ActiveMQ - User mailing list archive at Nabble.com.