6:56 p.m.
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. 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.
11:17 p.m.
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
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11:19 p.m.
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
>
11:42 p.m.
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:
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
12:58 a.m.
One of complains we got is about undertow & web subsystem sharing good
amount of message ids and messages in general.
Given that web subsystem will be removed soonish, does it make sense to
change ids for undertow or just keep the old ones (given that they have not
changed at all)
--
tomaz
On Wed, Jul 3, 2013 at 4:42 PM, Kabir Khan <kabir.khan(a)jboss.com> 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:
> 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
1:04 a.m.
On 03/07/13 16:58, Tomaž Cerar wrote:
One of complains we got is about undertow & web subsystem sharing
good
amount of message ids and messages in general.
Given that web subsystem will be removed soonish, does it make sense to
change ids for undertow or just keep the old ones (given that they have
not changed at all)
Are they reporting the same problem and do they have the same solution?
--
tomaz
On Wed, Jul 3, 2013 at 4:42 PM, Kabir Khan <kabir.khan(a)jboss.com
<mailto:kabir.khan@jboss.com>> 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:
> 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 <mailto:wildfly-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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 <mailto:wildfly-dev@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
1:29 a.m.
On 03/07/13 17:22, Tomaž Cerar wrote:
On Wed, Jul 3, 2013 at 6:04 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote:
Are they reporting the same problem and do they have the same solution?
They are exactly the same, same id and msg....
That wasn't my question ;-)
Do they have the same meaning and same solution?
Or if someone searches based on these IDs is it going to mean something
different when it applies to Undertow?
9:31 a.m.
There is a JIRA that I started on, but had to move off of due to a bug
in the annotation processor, https://issues.jboss.org/browse/WFLY-230.
Essentially I'm just going to add a @ValidIdRange annotation and give it
the valid range for the subsystem. The bug is now fixed in the
processor, so I can get working on this next week actually.
On 07/03/2013 02: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. 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
--
James R. Perkins
Red Hat JBoss Middleware
9:35 a.m.
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
4:47 p.m.
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
7:12 p.m.
+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
11:07 p.m.
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(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
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12:32 a.m.
On 7/3/13 11:29 AM, Darran Lofthouse wrote:
On 03/07/13 17:22, Tomaž Cerar wrote:
>
> On Wed, Jul 3, 2013 at 6:04 PM, Darran Lofthouse
> <darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote:
>
> Are they reporting the same problem and do they have the same solution?
>
> They are exactly the same, same id and msg....
That wasn't my question ;-)
Do they have the same meaning and same solution?
Or if someone searches based on these IDs is it going to mean something
different when it applies to Undertow?
I want to dodge this problem by redoing all of our log IDs before the
next beta release. Here's what I want to do:
1) Create a filtered _private subpackage in each WildFly module
2) Move all log messages to a single interface per modules
3) Renumber every log message, changing the project code from JBAS to
WFXXX where XXX is a sub-identifier for the module (e.g.
WFEE/WFEJB/WFHQ/WFWEB/...)
4) Create a mapping document which shows the mapping from JBAS messages
to the new codes, which can be used to seed KBs or whatever
5) Going forward, we will coordinate message IDs across different
project forks by using comments to block out IDs that exist only in
non-mainline forks (EAP) (but since WildFly will have new codes, it is
unlikely that the EAP 6.x cycle will introduce any conflicts; at most
we'll have to add new codes to the mapping doc from time to time when
fixes are backported)
I have already expressed some or all of this but I don't remember where
or when. ;) But hopefully this will shed some light. Or perhaps add
some confusion :)
--
- DML
6:05 a.m.
I'm taking it back. I'm not going to do WFLY-230 as David said he's
going to be changing id's and project codes anyway.
On 07/03/2013 02: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. 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
--
James R. Perkins
Red Hat JBoss Middleware
3954
days inactive
3961
days old
14 comments
8 participants
participants (8)
-
Brian Stansberry -
Carlo de Wolf -
Darran Lofthouse -
David M. Lloyd -
Jaikiran Pai -
James R. Perkins -
Kabir Khan -
Tomaž Cerar