2011/6/8 Manik Surtani <manik(a)jboss.org>:
> Any other ideas then, around this? Maybe a check during startup, when
ModuleCommandFactory. getModuleCommands() is invoked?
+1 we don't have to check for proper ranges, but we should check for duplicates.
We don't check for ranges either anywhere else.
We could also use markers to limit the duplicate checks. IOW, use a marker to define
internal commands (0) and another for externally defined user commands (1). So, then the
duplicates would be check in each scope. The scope of finding duplicates in internal
commands is there. So, we'd only need to check duplicates within user defined
commands.
>
>
> On 8 Jun 2011, at 15:42, Galder Zamarreño wrote:
>
>> So far command IDs have been bytes, so using ranges is harder. We'd need to
change them to short or something bigger to be able to use ID ranges relatively safely.
>>
>> On Jun 8, 2011, at 2:25 PM, Manik Surtani wrote:
>>
>>> Isn't the approach here to use well-known ID ranges? A bit like
externalizers?
>>>
>>> On 6 Jun 2011, at 11:29, Galder Zamarreño wrote:
>>>
>>>> Israel, do you have a test case for this?
>>>>
>>>> On Jun 6, 2011, at 7:23 AM, Israel Lacerra wrote:
>>>>
>>>>> Manik,
>>>>>
>>>>> I think there is a little problem. If a custom command use the same
id of a core command...no exception is thrown.
>>>>>
>>>>> cheers
>>>>>
>>>>> Israel
>>>>>
>>>>> On Thu, Mar 10, 2011 at 9:25 PM, Israel Lacerra
<israeldl(a)gmail.com> wrote:
>>>>> Manik,
>>>>>
>>>>> It's look pretty fine to me and will solve my problem :)
>>>>>
>>>>> Israel
>>>>>
>>>>> On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani
<manik(a)jboss.org> wrote:
>>>>>
>>>>> On 7 Mar 2011, at 13:02, Mircea Markus wrote:
>>>>>
>>>>>> Nice stuff!
>>>>>
>>>>> What do you think from the perspective of having to implement your
own commands, say for the continuous query prototype you did? Does it fit with that
model?
>>>>>
>>>>> Also, any more feedback from module authors that need this (looking
at Sanne and Israel!)? If not, I'll go ahead and issue a pull req...
>>>>>
>>>>> Cheers
>>>>> Manik
>>>>>
>>>>> --
>>>>> Manik Surtani
>>>>> manik(a)jboss.org
>>>>>
twitter.com/maniksurtani
>>>>>
>>>>> Lead, Infinispan
>>>>>
http://www.infinispan.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Manik Surtani
>>> manik(a)jboss.org
>>>
twitter.com/maniksurtani
>>>
>>> Lead, Infinispan
>>>
http://www.infinispan.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
>
twitter.com/maniksurtani
>
> Lead, Infinispan
>
http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache