Slogging through Logging
To my deep sadness, and complete lack of surprise, nobody has volunteered to take up logging integration while I was off working on Modules, so here I am again.
There are a bunch of logging topics to cover but I think we need to cover them now, since lack of good logging is already making life difficult on the front lines.
Domain Environment
Console Logging
We don't have a strategy for console logging in the domain environment. I think that whatever else may be decided, ultimately people will want to see important messages logged to the console, whether they have 5 servers or 500. If I'm right, then this implies that we need an aggregation strategy. We don't want to intermix a bunch of different formatting rules for example. Here's what I'm thinking:
- At the domain level, we have a "virtual console" handler type which uses the process manager messaging scheme to pass log messages on to the server manager using the PM API. This handler would have a very simple configuration consisting only of a level and optional filters.
- At the server manager level, we have a logging configuration which consists of either configuration at the host.xml level (which implies a bit of a can of worms relating to subsystems/profiles in host.xml), or just keeping the simple logging.properties from bootstrap. The server manager also receives and logs incoming messages from the server (logmanager already has all the stuff necessary to do this).
That's pretty much it. The message information can simply be serialized between the two systems. Because of the potential for a lot of messages, on the server side the level should be restricted as much as possible (WARN or higher I'm thinking). Also, the category name should be transformed or supplemented somehow with the server name to make filtering easier to accomplish on the server manager.
Bootstrap Logging
Right now everything that boots up via modules is using the same logger.properties to bootstrap, which is ugly at best. Ideally I'd like to see this happen:
- The server manager (SM) process is bootstrapped in one of the following ways:
- It uses a logging.properties for boot logging (which is a very short window) until it reads its host.xml and derives a logging configuration from it.
- Alternatively, it could use a logging.properties which exists solely for use of the SM in the configuration area instead. This would eliminate the two-phased logging thing which I think is a pain for users.
- The server's logging is bootstrapped in one of the following ways:
- The SM reads and understands the logger config from domain.xml, and passes it in at bootup, which immediately configures the server's logger environment in accordance with domain.xml.
- Each server has its own logging.properties which is used to perform bootstrap logging config until the logger subsystem is activated using the regular subsystem activation we use for everything else.
- Same as #2 only all servers share a common logging.properties.
For SM, I think option #2 is probably most practical. It'd only be a problem if we want to be able to manage the SM logging environment, which I view as non-required.
For Server bootstrapping, #1 is the best solution, but it can only work if the SM already understands the domain config. If so it'd be easy to put in special code to assemble a message or object model or something for the server to consume from main().
Standalone Environment
I think standalone ought to work much like AS6: a logging.properties is read and its configuration is used until the server logging subsystem comes up. No reason I can see to really deviate here.
Per-Deployment Logging Configuration
Back in the early days, if you wanted per-deployment logging config you basically had to include a log4j.jar in your deployment unit. With AS6 we became somewhat more sophisticated by detecting a logging deployment descriptor (jboss-logging.xml) and using information in that descriptor to create and configure an independent logging "context" without including a separate logging implementation.
In order to keep things managed under the domain model, it seems to me that we would have to put all this logging configuration into domain.xml. So if you want per-app logging you'd have to add another log context into the domain and then somehow tell the deployment system that you want your deployment to be attached to the specific alternative logging context. I think this would allow users to continue doing everything they do today; they may be opposed to the "how" though. I don't know.
Comments?
