On Tue, Apr 12, 2011 at 6:36 PM, Pierre-Arnaud Marcelot <[email protected]> 
wrote:
>
> On 12 avr. 2011, at 14:55, Emmanuel Lecharny wrote:
>
>> My message was not clear enough :
>>
>> what I meant is that the messageID should not be passed to the constructor, 
>> as it's not something a user will do. The LdapConnection class will create 
>> this message ID and pass it to the message through the setMessageId( ID ) 
>> method.
>>
>> In every place in the API where we want to set the ID (like in DSML or in 
>> the codec) it's the same thing : we cna use the setMessageID().
>>
>> Hope it's clear now ...
>
> Héhé, thanks for clarifying.
>
> I thought you wanted to get rid of the ability to set the ID by removing both 
> the constructor and the setter method.
>
> Removing the constructor with the message id parameter seems reasonable to me.
>
> As long as we can always set it via the setter method, I'm ok with that.
>
same here

> Regards,
> Pierre-Arnaud
>
>
>> On 4/12/11 2:27 PM, Emmanuel Lecharny wrote:
>>> Currently, we can inject a messageId in the Message constructors :
>>>
>>>    public AbandonRequestImpl( final int id )
>>>
>>> I don't think it's a good idea, as we usually generate those id 
>>> automatically (it's an incremental number).
>>>
>>> I suggest we don't inject the ID through the setMessageId( int ) if needed, 
>>> as usually we don't need to do that.
>>>
>>> Note that it's the same thing for all the requests.
>>>
>>> thoughts ?
>>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>
>



-- 
Kiran Ayyagari

Reply via email to