1 Reply Latest reply on Nov 16, 2010 6:11 AM by Brian Stansberry

    Logging deployment errors on start-up

    Alexey Loubyansky Master

      At the moment it's silent. Suppose there is a deployment unit in the repository and listed in the config in <deployments> which is invalid and can't be deployed. Starting the server (standalone, at least) the logs will contain a line like

       

      "INFO  [org.jboss.as.deployment] (pool-1-thread-2) Activating deployment: managedbeans.jar"

       

      but nothing more even if the deployment fails. One of the easiest ways to fix this would probably be using a UpdateResultHandler which would log things from AbstractServerModelUpdate

       

      {code}/**

           * Apply the boot action for this update.  This action is only executed when the update is processed during

           * server startup.  By default, this method simply invokes {@link #applyUpdate(UpdateContext, UpdateResultHandler, Object)}

           * directly, but this behavior should be overriden if a different action must be taken at boot time.

           *

           * @param updateContext the update context

           */

          public void applyUpdateBootAction(UpdateContext updateContext) {

              applyUpdate(updateContext, UpdateResultHandler.NULL, null);

          }{code}

      instead of using UpdateResultHandler.NULL.

       

      Any objections or other suggestions?

        • 1. Re: Logging deployment errors on start-up
          Brian Stansberry Master

          The DeploymentFailureListener should be logging if a service associated with the deployment fails. So the issue must be in the deployment chain.

           

          I like the idea of identifying one place that's responsible for logging errors. I'm not sure what it is though. Passing in a special UpdateResultHandler can work at boot, but then we'd want to make sure that the update classes don't log the error in applyUpdate. But then when applyUpdate is called any time other than boot, the special URH isn't there, and nothing gets logged.

           

          A solution to that is to ensure that any time we call applyUpdate we pass in the special URH. But, if the user themselves passed in a URH we'd have to use a wrapper that delegates to both our logging URH and the user's.