6 Replies Latest reply on Feb 19, 2009 12:07 PM by David Lloyd

    Logging integration requirements

    David Lloyd Master

      I've posted the logging integration requirements in a Wiki article here: https://www.jboss.org/community/docs/DOC-13346.

      If you have any comments or contributions, post them here or on the article. I'm developing this in earnest so if you have anything to say, say it now. :-) I intend to get this done in time for the first 5.1.0 beta.

        • 1. Re: Logging integration requirements
          Brian Stansberry Master

          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
            David Lloyd Master

             

            "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
              Scott Stark Master

              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
                Adrian Brock Master

                 

                "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
                  David Lloyd Master

                   

                  "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
                    David Lloyd Master

                    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).