[wildfly-dev] Update the Logging IDs Page

[Brian Stansberry]

I never delete messages from the files; I just comment them out. The CMP 
files being the extreme example.

I'll start rejecting any PRs I see that delete messages that were in 
.Final releases; I suggest all mergers should do the same.

On 7/4/13 5:12 AM, Darran Lofthouse wrote:
> +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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> James R. Perkins
>>> Red Hat JBoss Middleware
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat