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

[David M. Lloyd]

On 02/12/2014 09:50 AM, David M. Lloyd wrote:
> 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.

I want to elaborate on this a little bit.

The original commits here place log message interfaces and their 
generated classes into a separated packages, and, in most cases, then 
hides that package from importers, which decreases coupling.  However, 
when one module uses another's messages, we cannot do this as it would 
break the linkage of the consuming classes.

Looking at the code itself, there are a couple of sub-cases:

1) A module is really small and mostly just provides some new aspect of 
some existing thing, (see org.jboss.as.management.client.content.*)

2) The module in question has its own IDs, but an ID from a different 
module seems more relevant, e.g. connector and ejb3 using several EE 
messages (see commit titled '[WFLY-2864] WildFly EE module')

3) The module in question has no IDs and defining one doesn't seem worth 
it, given there are other modules that have the same one or two messages 
that it needs and they seem relevant enough (see CLI module, using 
messages from controller)

For all of these cases, I think the right thing to do (assuming we don't 
simply solve these cases in some trivial way) may be to factor the log 
messages out into a separate, shared maven module which contains only 
these messages.  When we split the distribution, a key question will be 
"how do we divide the modules along dependency-sane lines, and what 
dependencies then exist between them?"  The answer to this question may 
be simpler to ascertain if logging messages are factored out this way, 
especially if this would allow us to break some circularity in the case 
where the log messages are the only reason for a dependency.

-- 
- DML