Any special reason we are sticking with org.jboss.as.* categories for all
the logging stuff?
given that we are refactoring everything to have different logging codes,
we could do change to org.wildfly.* as well.
On Wed, Feb 12, 2014 at 7:45 PM, David M. Lloyd <david.lloyd(a)redhat.com>wrote:
Yeah this is a raw, tab-delimited, N:1 mapping of old codes to new
codes. I'm hoping that this form will be transmutable into any form we
need with a minimum of headache. Here's a better link that will evolve
with the PR:
Note that the final PR doesn't have to include this file (and probably
shouldn't), but it was a good way to track the ID mappings per commit.
On 02/12/2014 12:34 PM, James R. Perkins wrote:
> Not sure on the final plans on how to present it, but currently there is
> in the root directory.
> On 02/12/2014 10:26 AM, Brian Stansberry wrote:
>> What's the plan re: item 4 from your post at  from last July?
>> "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"
>> On 2/12/14, 9:50 AM, David M. Lloyd wrote:
>>> It's right there in the topic. James and I have carried out the change
>>> discussed in  and elsewhere, and have split all the old "JBAS"
>>> into specific "WFLYxxx" codes. The pull request is divided into
>>> commit per Maven module for easier review.
>>> I request that every subsystem or component maintainer please review
>>> part of the commit that pertains to their piece, and please post
>>> comments on the PR itself .
>>> In addition, I want to discuss a few cases where modules are using
>>> message bundles and loggers from neighboring modules. This is going to
>>> become a problem when we do the distribution split-up.
>>> Finally, one small matter I want to sort out is that we have several
>>> modules which use a project-specific code for IllegalArugmentExceptions
>>> that pertain specifically to null parameters, whereas some do not use a
>>> code for this case and just throw the exception.
>>> My feeling is we should either (a) don't use a code for this kind of
>>> thing, or (b) come up with a "common" module or code space+project
>>> which every project can reuse, so we just have one code that
>>> means "the parameter can't be null".
>>>  http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000428.html
>>>  https://github.com/wildfly/wildfly/pull/5906
wildfly-dev mailing list