-
1. Re: Logging integration requirements
Just an FYI in case relevant: the AS uses a forked version of commons-logging, particularly the Log4jLogger class. And, at least for a portion of startup, JBossTS programatically sets the default implementation of the commons-logging Log interface, setting it to com.arjuna.common.internal.util.logging.jakarta.Log4JLogger.
A thread where some issues related to that were discussed:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=129207 -
2. Re: Logging integration requirements
"bstansberry@jboss.com" wrote:
Just an FYI in case relevant: the AS uses a forked version of commons-logging, particularly the Log4jLogger class. And, at least for a portion of startup, JBossTS programatically sets the default implementation of the commons-logging Log interface, setting it to com.arjuna.common.internal.util.logging.jakarta.Log4JLogger.
A thread where some issues related to that were discussed:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=129207
Ugh. I remember this problem, but I didn't remember that the solution was such crap. Well, one good thing about the MC is that we can just give JBossTS its own commons-logging instance. That might just be the solution - isolate it and let it do its own thing. I'll look more once I get closer to completing the integration... -
3. Re: Logging integration requirements
Related to better tools integration, a notion of being able to capture all logging related to a deployment. In reality I think all we can do is capture the logging related to a MainDeployer.process context, but for the tools, this will generally be just for their deployment so it should be sufficient.
-
4. Re: Logging integration requirements
"scott.stark@jboss.org" wrote:
Related to better tools integration, a notion of being able to capture all logging related to a deployment. In reality I think all we can do is capture the logging related to a MainDeployer.process context, but for the tools, this will generally be just for their deployment so it should be sufficient.
There already is a way to capture "deployment" (really context classloader) logging
http://www.jboss.org/community/docs/DOC-11277
But I don't think that will capture all the deployment time logging since the application's
TCL is only set for a very brief period during that time (e.g. during servlet initialization).
I did do some stuff a long time ago where you could add "call logging"
where you collect all logging for a particular thread/invocation on the server
and then log it on the client.
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/aop/trunk/aspects/src/main/java/org/jboss/aspects/logging/
but it only works if you use aop-remoting. -
5. Re: Logging integration requirements
"scott.stark@jboss.org" wrote:
Related to better tools integration, a notion of being able to capture all logging related to a deployment. In reality I think all we can do is capture the logging related to a MainDeployer.process context, but for the tools, this will generally be just for their deployment so it should be sufficient.
It looks like one way, or perhaps the (recommended?) way to do this today is with TCLFilter, though I don't know if this is adequate, or if filters are the way to go going forward (once you get a few going, that might start to incur a pretty substantial overhead).
Making an isolated logging context based on the process context is another idea, but even if there wasn't a bunch of work to make this work, this will only capture log messages directly generated by the deployment, not by other modules involved in actions performed by or on behalf of the deployment, which may or may not be useful (I think this is what you're referring to)? -
6. Re: Logging integration requirements
Trying to put this more plainly, if I were looking at it from a user's perspective, my expectation might fall along one of these lines:
1) All log messages that originate from my log categories get handled separately.
2) All log messages that originate from loggers within my deployment (regardless of category) get handled separately.
3) All log messages that originate or relate to my deployment in any way (regardless of category or originating module) get handled separately.
We obviously can do (1) now with no changes. The question is, do we want to do (2) or (3)? Are existing solutions good enough? Even (3) is doable, if we're willing to monkey with the microcontainer enough to provide hooks into any code that invokes a task or method in a user's deployment (maybe these hooks already exist and we just aren't utilizing them).