Ok, but how then can I check if it was created with an offset and get
'proper' byte buffer? All usages I can find in samples just check if it's
not composite and call toByteBuffer.
I'm getting the 'wrong' byteBuffer from Grizzly Buffer obtained from
ctx.getMessage() in a filter and have no control upon its creation, I just
call myConnection.write(new ByteBufferWrapper(requetBytes)) (as you
suggested here before). But I still want to keep my code using 'pure' nio
types and thus want to get bytebuffer from grizzly buffer.
Best regards, Eugene.
2014-11-27 19:01 GMT+02:00 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>:
> Hi,
>
> yes, it's normal.
> Grizzly Buffer may wrap a ByteBuffer with a specific offset or just a part
> of ByteBuffer (view), which you have to consider.
> Normally when you do toByteBuffer() - the returned ByteBuffer's position
> and limit will represent current Grizzly Buffer's view.
>
> WBR,
> Alexey.
>
>
> On 27.11.14 08:12, Евгений Бушуев wrote:
>
>> Hi!
>>
>> Is it legal for a org.glassfish.grizzly.Buffer
>> (org.glassfish.grizzly.memory.HeapMemoryManager.TrimmableHeapBuffer#TrimmableHeapBuffer)
>> to return ByteBuffer from its toByteBuffer method so that ByteBuffer's
>> content won't be same as in original grizzly.Buffer?
>>
>> Can't figure out why this happens, seems to be random. The grizzly.Buffer
>> instance is not composite.
>>
>> Best regards, Eugene.
>>
>
>