[wildfly-dev] The Big Log ID Change: https://github.com/wildfly/wildfly/pull/5906

[Tomaž Cerar]

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 at 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:
>
> https://github.com/dmlloyd/wildfly/blob/wfly-2864-log-messages/log-ids.txt
>
> 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
> >
> https://github.com/dmlloyd/wildfly/blob/cf6775eb53204b8bdad4e5cd9d3445bd1395b6fa/log-ids.txt
> > 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 [1] 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 [1] and elsewhere, and have split all the old "JBAS" codes
> >>> into specific "WFLYxxx" codes.  The pull request is divided into one
> >>> commit per Maven module for easier review.
> >>>
> >>> I request that every subsystem or component maintainer please review
> the
> >>> part of the commit that pertains to their piece, and please post
> >>> comments on the PR itself [2].
> >>>
> >>> 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 code
> >>> which every project can reuse, so we just have one code that
> universally
> >>> means "the parameter can't be null".
> >>>
> >>> [1] http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000428.html
> >>> [2] https://github.com/wildfly/wildfly/pull/5906
> >>>
> >>
> >
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140218/8b5d77f3/attachment.html