4:28 p.m.
I've merged the branch in which I and ALR updated the logging service and
bootstrap, respectively. Here's the gist of the logging changes:
- The log4j-boot.jar hack is gone
- The default log implementation is now jboss-logmanager
- Log4jService is gone
- The boot-time log config is slightly different (see
"system/src/resources/logging.properties")
- Run-time log config now uses SchemaResolverDeployer to deploy
jboss-logging.xml (located in deploy/, not conf/, due to the way the new MC
deployer system works; look in deployers/ for more information about how
the POJO log service works)
- All log messages produced by slf4j, jboss-logging, commons-logging,
log4j, and JDK logging are all properly routed through the log system
As things stand, server startup should be slightly faster than it was
before, though jbossxb parsing of jboss-logging.xml actually slows things
down rather more than I expected, and I haven't checked to see if this
offsets the performance gain. Run-time performance of logging should be
much faster than it was under log4j.
Let the pain & mayhem begin.
- DML
7:35 a.m.
Hi David,
David M. Lloyd wrote:
This would mean that the appenders/handlers
for server.log would be
created when the jboss-logging.xml is picked from the deploy folder.
Wouldn't it be too late? I mean the server.log would no longer contain
most of the logs from the deployers/deployments prior to the
jboss-logging.xml being configured, isn't it? The logs prior to this
configuration being picked up, would be logged to boot.log which is
controlled through the logging.properties within the
JBOSS_HOME/bin/run.jar file. So configuring the logging.properties would
involve unzipping and updating the logging.properties and zipping back
the archive. Would it be possible to handle this in a better way?
By the way, is the xsd for the jboss-logging.xml available for reference?
regards,
-Jaikiran
10:34 a.m.
On 07/15/2009 07:35 AM, Jaikiran Pai wrote:
Yeah, *if* we come up with a sort of "config-deploy" folder that is
deployed after deployers but before deploy. I think this will be a common
problem as more and more things are POJO-ized. Maybe we should have one
"master" configuration file which covers everything, placed in this
location. Or maybe not. :-)
Another option would be to put the deployer *and* the config file into the
bootstrap process, which I don't want to do (I'd rather have a more
general-purpose solution). Alternately, I could have left it in conf/ and
added a bootstrap step to deploy it separately, but then it would be
impossible to redeploy/reconfigure logging.
By the way, is the xsd for the jboss-logging.xml available for
reference?
Yes, right here:
http://anonsvn.jboss.org/repos/jbossas/projects/logging-service-metadata/...
- DML
1:33 p.m.
David M. Lloyd wrote:
It depends when we want the logging service to
be started. I guess, the
best time would be to start the logging service as soon as the bootstrap
is done so that the logging service can capture and log as much
information as possible. I agree with the "config-deploy" sort of
necessity which might be required going forward (or i think it will get
addressed if we move to the system-apps-deploy folder sort of thing that
we discussed some time back). But i guess in case of the
logging-service, it still would be too late because we would have either
lost or would be difficult to configure the logging for the "deployers"
since the logging service would start after the "deployers".
As far as the logging service is concerned, i guess this would make
sense (i.e. leaving it in conf/). The earlier version of the logging
service (which used jboss-log4j.xml) worked around the
redeploy/reconfigure issue by setting up a Log4jTimerServi ceTask which
was a timer task (default 60 sec.) which would pick up the changes to
the logging configuration file. Maybe we could do something similar?
regards,
-Jaikiran
5732
days inactive
5738
days old
jboss-development@lists.jboss.org
4 comments
2 participants
participants (2)
-
David M. Lloyd -
Jaikiran Pai