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) A module is really small and mostly just provides some new aspect of some existing thing, (see org.jboss.as.management.client.content.*)

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

Not sure on the final plans on how to present it, but currently there is https://github.com/dmlloyd/wildfly/blob/cf6775eb53204b8bdad4e5cd9d3445bd1... 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 >> >

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/cf6775eb53204b8bdad4e5cd9d3445bd1... > 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

FYI, Brian just merged this change. On 02/12/2014 09: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 >