You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2012/11/08 11:24:12 UTC

Re: git commit: WICKET-4859 change component id counter to long, similar to RepeatingView

On Thu, Nov 8, 2012 at 10:02 AM,  <sv...@apache.org> wrote:
> -       private static int counter = 0;
> +       /** Counter used for generating unique component ids. */
> +       private static long counter = 0;

Should this be an AtomicLong instead? Statics make me cringe in a
multithreaded environment.

Martijn

Re: git commit: WICKET-4859 change component id counter to long, similar to RepeatingView

Posted by Igor Vaynberg <ig...@gmail.com>.
its not for convenience. without this autogenerated id the user would
have to specify it and make sure it is unique across all toolbars in
the datatable. when the datatable is created/configured via several
methods this can be a headache. also, the ids do not matter because
they are used in the repeater.

-igor

On Thu, Nov 8, 2012 at 4:12 AM, Sven Meier <sv...@meiers.net> wrote:
>>Statics make me cringe
>
> Me too.
>
> I'm not sure about the need of an AtomicLong. I've just took the easy route
> and changed it to how RepeatingView works.
>
>
>> why does the counter have to be globally unique?
>
> See my last comment on the issue: It's just that toolbars have an auto
> generated id (for convenience?).
>
> Sven
>
>
> On 11/08/2012 11:26 AM, Martijn Dashorst wrote:
>>
>> On Thu, Nov 8, 2012 at 11:24 AM, Martijn Dashorst
>> <ma...@gmail.com> wrote:
>>>
>>> On Thu, Nov 8, 2012 at 10:02 AM,  <sv...@apache.org> wrote:
>>>>
>>>> -       private static int counter = 0;
>>>> +       /** Counter used for generating unique component ids. */
>>>> +       private static long counter = 0;
>>>
>>> Should this be an AtomicLong instead? Statics make me cringe in a
>>> multithreaded environment.
>>
>> On second thought: why does the counter have to be globally unique?
>> Doesn't that make it rather an issue with long running applications
>> where markup ids generated from component ids get very long?
>>
>> Martijn
>
>

Re: git commit: WICKET-4859 change component id counter to long, similar to RepeatingView

Posted by Sven Meier <sv...@meiers.net>.
 >Statics make me cringe

Me too.

I'm not sure about the need of an AtomicLong. I've just took the easy 
route and changed it to how RepeatingView works.

 > why does the counter have to be globally unique?

See my last comment on the issue: It's just that toolbars have an auto 
generated id (for convenience?).

Sven

On 11/08/2012 11:26 AM, Martijn Dashorst wrote:
> On Thu, Nov 8, 2012 at 11:24 AM, Martijn Dashorst
> <ma...@gmail.com> wrote:
>> On Thu, Nov 8, 2012 at 10:02 AM,  <sv...@apache.org> wrote:
>>> -       private static int counter = 0;
>>> +       /** Counter used for generating unique component ids. */
>>> +       private static long counter = 0;
>> Should this be an AtomicLong instead? Statics make me cringe in a
>> multithreaded environment.
> On second thought: why does the counter have to be globally unique?
> Doesn't that make it rather an issue with long running applications
> where markup ids generated from component ids get very long?
>
> Martijn


Re: git commit: WICKET-4859 change component id counter to long, similar to RepeatingView

Posted by Martijn Dashorst <ma...@gmail.com>.
On Thu, Nov 8, 2012 at 11:24 AM, Martijn Dashorst
<ma...@gmail.com> wrote:
> On Thu, Nov 8, 2012 at 10:02 AM,  <sv...@apache.org> wrote:
>> -       private static int counter = 0;
>> +       /** Counter used for generating unique component ids. */
>> +       private static long counter = 0;
>
> Should this be an AtomicLong instead? Statics make me cringe in a
> multithreaded environment.

On second thought: why does the counter have to be globally unique?
Doesn't that make it rather an issue with long running applications
where markup ids generated from component ids get very long?

Martijn