[MINA 3] IoBuffer
Hi guys, I have just committed [1] two classes (IoBuffer and IoBufferTest). The IoBuffer class is not completed yet, but will be soon. The IoBuffer class just has the same methods than a ByteBuffer, except that internally it stores a list of ByteBuffers. We don't make the IoBuffer expendable anymore, we can expand it by adding a new ByteBuffer at the end. Otherwise, all the methods mimic the ByteBuffer methods, as if you don't see the interned ByteBuffer. Feel free to comment... Thanks ! [1] http://svn.apache.org/viewvc?rev=1206386&view=rev -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3] IoBuffer
On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharny wrote: > Hi guys, > Hi Emmanuel, > Feel free to comment... > ...here we go! Using the 2 MINA IoBuffer is difficult for us because the documentation of it is too hard to reach. JavaDoc's like "@see # xy ByteBuffer (..)" only makes sense if the IDE displays the linked API docu immediately, otherwise it's far from fun. I think the most of us don't like to lookup the ByteBuffer docu, we want it first hand! We look into the JavaDoc because we need it, just in this moment. So what is more expressive: /** * @see Buffer#hasRemaining() */ vs. /** * Tells whether there are any elements between the current position and the limit. * * @returns true if, and only if, there is at least one element remaining in this buffer */ WDYT? Best regards Christian
Re: [MINA 3] IoBuffer
...one more thing, the sun.reflect.generics.reflectiveObjects.NotImplementedException's should be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the compilation because the NotImplementedException is not public API (access restriction). On Sun, Nov 27, 2011 at 10:05 PM, Christian Schwarz < chriss@googlemail.com> wrote: > On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharny wrote: > >> Hi guys, >> > > Hi Emmanuel, > > >> Feel free to comment... >> > > ...here we go! Using the 2 MINA IoBuffer is difficult for us because the > documentation of it is too hard to reach. JavaDoc's like "@see # xy > ByteBuffer (..)" only makes sense if the IDE displays the linked API docu > immediately, otherwise it's far from fun. I think the most of us don't like > to lookup the ByteBuffer docu, we want it first hand! We look into the > JavaDoc because we need it, just in this moment. > So what is more expressive: > > /** > * @see Buffer#hasRemaining() > */ > > vs. > > /** > * Tells whether there are any elements between the current position and > the limit. > * > * @returns true if, and only if, there is at least one element remaining > in this buffer > */ > > WDYT? > > Best regards > Christian >
Re: [MINA 3] IoBuffer
On 11/27/11 10:05 PM, Christian Schwarz wrote: On Sat, Nov 26, 2011 at 1:39 AM, Emmanuel Lecharnywrote: Hi guys, Hi Emmanuel, Feel free to comment... ...here we go! Using the 2 MINA IoBuffer is difficult for us because the documentation of it is too hard to reach. JavaDoc's like "@see # xy ByteBuffer (..)" only makes sense if the IDE displays the linked API docu immediately, otherwise it's far from fun. I think the most of us don't like to lookup the ByteBuffer docu, we want it first hand! We look into the JavaDoc because we need it, just in this moment. So what is more expressive: /** * @see Buffer#hasRemaining() */ vs. /** * Tells whether there are any elements between the current position and the limit. * * @returns true if, and only if, there is at least one element remaining in this buffer */ WDYT? I agree. What made me use the @see tag is that it was fast and easy. I do think that it would be better to include some documentation associated to this @see tag. The main issue is that we *must* not copy the original doco (which is copyaighted). -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3] IoBuffer
On 11/27/11 10:18 PM, Christian Schwarz wrote: ...one more thing, the sun.reflect.generics.reflectiveObjects.NotImplementedException's should be replaced by java.lang.UnsupportedOperationException's. My IDE refuse the compilation because the NotImplementedException is not public API (access restriction). Right ! Btw, I will implement the missing code soon, so it's just a placeholder atm. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3] IoBuffer
On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny
wrote:
> On 11/27/11 10:18 PM, Christian Schwarz wrote:
>>
>> ...one more thing,
>>
>> the sun.reflect.generics.reflectiveObjects.NotImplementedException's
>> should
>> be replaced by java.lang.UnsupportedOperationException's. My IDE refuse
>> the
>> compilation because the NotImplementedException is not public API (access
>> restriction).
>
> Right !
>
> Btw, I will implement the missing code soon, so it's just a placeholder
> atm.
>
We bneed commons coding rules because I used "new
RuntimeException("not implemented")"
Julien
[MINA 3] IoBuffer thoughts
Hi guys, we discussed a bit about this IoBuffer thing I'm working on with Julien today. It seems that we don't need an acumulating buffer anywhere but in the decoder (all in all, we don't expect the filters to use an IoBuffer in the messageReceined() method. It's expecting an Object. This Object is cast to a ByteBuffer only when processed by the decoder). So we may want to make this class a hidden one for the common user, except for those who want to write their own decoder. The selector will always store the incoming data into a ByteBuffer, and propagate it as is into the chain (that raises an other question : why do we reuse one single ByteBuffer for that purpose? We may want to coy this data into a separate buffer. Also the buffer *must* be associated with the current session, not with the selector, otherwise we won't be able to process more than one session at a time (assuming we may have an executor somewhere down the chain)). I would suggest that the selector copy the read data into the session's buffer (which size should be configurable), and then passed into the chain. When the decoder try to process the incoming message, we can cumulate the BB ino the BufferList class... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[Mina 3] exceptions was Re: [MINA 3] IoBuffer
On 11/28/11 9:43 AM, Julien Vermillard wrote:
On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny
wrote:
On 11/27/11 10:18 PM, Christian Schwarz wrote:
...one more thing,
the sun.reflect.generics.reflectiveObjects.NotImplementedException's
should
be replaced by java.lang.UnsupportedOperationException's. My IDE refuse
the
compilation because the NotImplementedException is not public API (access
restriction).
Right !
Btw, I will implement the missing code soon, so it's just a placeholder
atm.
We bneed commons coding rules because I used "new
RuntimeException("not implemented")"
We certainly need to define a common set of exceptions we should use at
Mina. MinaException. We should also discuss if we want them to be
runtime or checked exceptions.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Mina 3] exceptions was Re: [MINA 3] IoBuffer
On Mon, Nov 28, 2011 at 10:05 AM, Emmanuel Lécharny
wrote:
> On 11/28/11 9:43 AM, Julien Vermillard wrote:
>>
>> On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny
>> wrote:
>>>
>>> On 11/27/11 10:18 PM, Christian Schwarz wrote:
...one more thing,
the sun.reflect.generics.reflectiveObjects.NotImplementedException's
should
be replaced by java.lang.UnsupportedOperationException's. My IDE refuse
the
compilation because the NotImplementedException is not public API
(access
restriction).
>>>
>>> Right !
>>>
>>> Btw, I will implement the missing code soon, so it's just a placeholder
>>> atm.
>>>
>> We bneed commons coding rules because I used "new
>> RuntimeException("not implemented")"
>
> We certainly need to define a common set of exceptions we should use at
> Mina. MinaException. We should also discuss if we want them to be runtime or
> checked exceptions.
>
On the check/runtime :
checked are usual error which should be handled by the API user : a
decoding error because the client is sending craps
runtime are for bug or problem the API can't do much, he just want to
log the error : NPE, socket exceptions, not implemented exception
Julien
Re: [Mina 3] exceptions was Re: [MINA 3] IoBuffer
On 28 November 2011 09:38, Julien Vermillard wrote:
> On Mon, Nov 28, 2011 at 10:05 AM, Emmanuel Lécharny
> wrote:
>> On 11/28/11 9:43 AM, Julien Vermillard wrote:
>>>
>>> On Sun, Nov 27, 2011 at 11:33 PM, Emmanuel Lécharny
>>> wrote:
On 11/27/11 10:18 PM, Christian Schwarz wrote:
>
> ...one more thing,
>
> the sun.reflect.generics.reflectiveObjects.NotImplementedException's
> should
> be replaced by java.lang.UnsupportedOperationException's. My IDE refuse
> the
> compilation because the NotImplementedException is not public API
> (access
> restriction).
Right !
Btw, I will implement the missing code soon, so it's just a placeholder
atm.
>>> We bneed commons coding rules because I used "new
>>> RuntimeException("not implemented")"
>>
>> We certainly need to define a common set of exceptions we should use at
>> Mina. MinaException. We should also discuss if we want them to be runtime or
>> checked exceptions.
>>
>
> On the check/runtime :
> checked are usual error which should be handled by the API user : a
> decoding error because the client is sending craps
+1
Generally used for recoverable conditions.
> runtime are for bug or problem the API can't do much, he just want to
> log the error : NPE, socket exceptions, not implemented exception
Not sure about socket exception - that may be transient, e.g.
temporary lack of resources
Also, please use standard Exceptions for standard errors rather than
creating subclasses of existing ones.
Sometimes it is necessary to create new Exceptions/Errors, but that
should be the exception (!).
> Julien
>
