Jopr (CLOSED)
  1. Jopr (CLOSED)
  2. JOPR-381

Any error in the package installation workflow is silently ignored

    Details

    • Estimated Difficulty:
      Low
    • Similar Issues:
      Show 10 results 

      Description

      Any error in the package installation steps that is reported using the error() method in the step handlers is silently ignored.

      The plugins share a common library that implements the common functionality for package installation including a number of installation step handlers. Both AS4 and AS5 plugins include this as a dependent jar in their /lib directory.

      In this library the error() method implemented in BaseHandler class uses StringUtil class from RHQ clientapi.

      At runtime the following exception is thrown:

      org.jbpm.graph.def.DelegationException
      at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:349)
      at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:343)
      at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:343)
      at org.jbpm.graph.def.Node.execute(Node.java:332)
      at org.jbpm.graph.def.Node.enter(Node.java:316)
      at org.jbpm.graph.def.Transition.take(Transition.java:119)
      at org.jbpm.graph.def.Node.leave(Node.java:382)
      at org.jbpm.graph.node.StartState.leave(StartState.java:70)
      at org.jbpm.graph.exe.Token.signal(Token.java:174)
      at org.jbpm.graph.exe.Token.signal(Token.java:123)
      at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:217)
      at org.jboss.on.common.jbossas.JBPMWorkflowManager.run(JBPMWorkflowManager.java:156)
      at org.rhq.plugins.jbossas5.ApplicationServerContentFacetDelegate.deployPackages(ApplicationServerContentFacetDelegate.java:110)
      at org.rhq.plugins.jbossas5.ApplicationServerComponent.deployPackages(ApplicationServerComponent.java:279)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at java.lang.Thread.run(Thread.java:619)
      Caused by: java.lang.NoClassDefFoundError: org/rhq/core/clientapi/util/StringUtil
      at com.jboss.jbossnetwork.product.jbpm.handlers.BaseHandler.logStep(BaseHandler.java:258)
      at com.jboss.jbossnetwork.product.jbpm.handlers.BaseHandler.error(BaseHandler.java:155)
      at com.jboss.jbossnetwork.product.jbpm.handlers.JONServerDownloadActionHandler.run(JONServerDownloadActionHandler.java:57)
      at com.jboss.jbossnetwork.product.jbpm.handlers.BaseHandler.execute(BaseHandler.java:135)
      at org.jbpm.graph.def.Action.execute(Action.java:123)
      at org.jbpm.graph.def.Node.execute(Node.java:328)
      ... 20 more

      but JBPMWorkflowManager merely logs this exception and continues without rethrowing it. The calling code then errorneously thinks that everything succeeded when it didn't.

        Activity

        Hide
        John Mazzitelli
        added a comment -

        plugins are not allowed to access classes from clientapi package - they are off limits:

        // These core agent/plugin container libraries are not to be used by the plugins.
        // We hide them to enforce this - plugin developers should not be using these.
        defaultRegex.append("(org\\.rhq\\.core\\.clientapi
        ..*)|");

        you need to write your own utility

        Show
        John Mazzitelli
        added a comment - plugins are not allowed to access classes from clientapi package - they are off limits: // These core agent/plugin container libraries are not to be used by the plugins. // We hide them to enforce this - plugin developers should not be using these. defaultRegex.append("(org\\.rhq\\.core\\.clientapi ..*)|"); you need to write your own utility
        Hide
        John Mazzitelli
        added a comment -

        the only thing this BaseHandler needs StringUtil for is:

        String errorMessage = StringUtil.getStackTrace(throwable);

        and we have these in the core utils (not in clientapi - these ARE available to plugins):

        ThrowableUtil
        ExceptionPackage

        You can use them to get strings of the error messages and strings of the stack traces.

        Or just do it yourself this getStackTrace stuff is trivial to implement as, say , a private method directly in BaseHandler

        Show
        John Mazzitelli
        added a comment - the only thing this BaseHandler needs StringUtil for is: String errorMessage = StringUtil.getStackTrace(throwable); and we have these in the core utils (not in clientapi - these ARE available to plugins): ThrowableUtil ExceptionPackage You can use them to get strings of the error messages and strings of the stack traces. Or just do it yourself this getStackTrace stuff is trivial to implement as, say , a private method directly in BaseHandler
        Hide
        John Mazzitelli
        added a comment -

        this means we can never apply patches. this is a blocker.

        Show
        John Mazzitelli
        added a comment - this means we can never apply patches. this is a blocker.
        Hide
        John Mazzitelli
        added a comment -

        recommendation. change this:

        String errorMessage = StringUtil.getStackTrace(throwable);

        to:

        String errorMessage = new org.rhq.core.util.exception.ExceptionPackage(throwable).getStackTraceString();

        If its possible that throwable can be null, wrap this in a "if throwable != null".

        Show
        John Mazzitelli
        added a comment - recommendation. change this: String errorMessage = StringUtil.getStackTrace(throwable); to: String errorMessage = new org.rhq.core.util.exception.ExceptionPackage(throwable).getStackTraceString(); If its possible that throwable can be null, wrap this in a "if throwable != null".
        Hide
        Ian Springer
        added a comment -

        r1204 fixes the StringUtil issue with the replacement code recommended by Mazz. I'm leaving this issue open though, since we still need to look into improving the exception handling when RuntimeExceptions occur within patch install process steps. We should probably log them - the question is, at what level.

        Show
        Ian Springer
        added a comment - r1204 fixes the StringUtil issue with the replacement code recommended by Mazz. I'm leaving this issue open though, since we still need to look into improving the exception handling when RuntimeExceptions occur within patch install process steps. We should probably log them - the question is, at what level.
        Hide
        John Mazzitelli
        added a comment -

        r1209 completes the fix that r1204 started - I just had to remove the import of that clientapi StringUtil class.

        Show
        John Mazzitelli
        added a comment - r1209 completes the fix that r1204 started - I just had to remove the import of that clientapi StringUtil class.

          People

          • Assignee:
            Unassigned
            Reporter:
            Lukas Krejci
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 2 hours
              2h
              Remaining:
              Remaining Estimate - 2 hours
              2h
              Logged:
              Time Spent - Not Specified
              Not Specified