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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat