+1 - Similar to schema versions being 'protected' once included in a
.Final tag we should maintain a record of the IDs as each release is tagged.
If a message is deleted in the middle of the range its reuse should be
easy to spot in subsequent pull requests but if the last message was
deleted its reuse would not be detectable.
Regards,
Darran Lofthouse.
On 04/07/13 08:47, Carlo de Wolf wrote:
We actually need a report (/guard) that goes across multiple
versions
(including EAP).
Carlo
On 07/04/2013 02:35 AM, James R. Perkins wrote:
>
> On 07/03/2013 07:42 AM, Kabir Khan wrote:
>> I also had a vague thought about this. Perhaps the logging annotation processor
could be changed to dump a target/logging-ids.txt file for each subsystem, which we could
then use to do a check at the end of the build.
>> On 3 Jul 2013, at 15:19, Jaikiran Pai wrote:
> There is actually LOGTOOL JIRA (
>
https://issues.jboss.org/browse/LOGTOOL-74) to generate reports of the
> log id and message. I haven't done anything with it yet, but a simple
> text file would be easy enough. My initial thought was to feed a
> format in since it would essentially become a table of some sort.
>>> I wonder, if we could somehow integrate these checks and maintaining of
>>> the range, within the build. I _think_ it should be possible to do it,
>>> but I haven't thought much about it yet.
>>>
>>> -Jaikiran
>>> On Wednesday 03 July 2013 07:47 PM, Brian Stansberry wrote:
>>>> On 7/3/13 4:56 AM, Darran Lofthouse wrote:
>>>>> Hi all,
>>>>>
>>>>> Recently we have had some issues reported where logging IDs are
>>>>> suspected to be duplicates.
>>>>>
>>>>> Can I suggest that one thing we do need is to update the page
tracking
>>>>> the reserved ID's to make it easier to identify what block is
available
>>>>> next?
>>>>>
>>>>>
https://community.jboss.org/wiki/LoggingIds
>>>>>
>>>>> Would it would be easier if the ranges column was sequential, if a
>>>>> subsystem takes multiple allocations then it should just appear in
the
>>>>> list more than once.
>>>> If I understand what you're saying correctly, what you describe is
the
>>>> way it's meant to be. A quick scan shows it follows that pattern,
except
>>>> for CMP which didn't have multiple lines in the table. I fixed that.
If
>>>> there are others that don't follow the pattern they should be fixed.
>>>>
>>>>> At the moment to find a free block you need to
>>>>> scan up and down the page to check the subsequent allocations.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> ---------------------------------------
>> Kabir Khan
>> Prinicipal Software Engineer
>> JBoss by Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> James R. Perkins
> Red Hat JBoss Middleware
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev