sailfin
  1. sailfin
  2. SAILFIN-1018

Difference when using JSR88 and admin webGUI for deployment

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: milestone 1
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: PC

      Description

      This problem is noticed on SCAS R1C.
      There seems to be some issue when deploying modules with JSR88. In or case we
      have a.ear that has dependency to b.rar. If deploying (with the admin webGUI)
      our-ear-1.0.ear before deploying our-rar-1.0.rar, the exception in the attached
      file error.log will appear. It is verified that if that deploying the rar first
      and then the ear works, and deployment is successfully completed.
      However, if deploying the rar first, and the deploying the ear with JSR88, the
      same exception as when the rar isnt deployed at all, will appear, see the
      attachment.

      1. deployRAR_das_server.log
        0.3 kB
        stefanvahlgren
      2. deployRAR_instance1_server.log
        0.5 kB
        stefanvahlgren
      3. error.log
        5 kB
        stefanvahlgren

        Activity

        Hide
        sanandal added a comment -

        Marked keyword as shark-approved

        Show
        sanandal added a comment - Marked keyword as shark-approved
        Hide
        Hong Zhang added a comment -

        I was able to reproduce the problem with the latest instructions and test cases.

        The problem turned out to be in constructing the shared classloader in the
        classloader hirarchy (where the connector modules are added).

        The DeploymentUtils calls the BaseManager.getSharedClasspath to construct the
        shared classloader and the BaseManager.getSharedClasspath always assumed the
        target is a standalone server and not a cluster (I tried the standalone remote
        instance case, it did work).

        So the fix is to handle the case where the target is a cluster in
        BaseManager.getSharedClasspath.

        Will check in fix soon after the code is reviewed.

        Show
        Hong Zhang added a comment - I was able to reproduce the problem with the latest instructions and test cases. The problem turned out to be in constructing the shared classloader in the classloader hirarchy (where the connector modules are added). The DeploymentUtils calls the BaseManager.getSharedClasspath to construct the shared classloader and the BaseManager.getSharedClasspath always assumed the target is a standalone server and not a cluster (I tried the standalone remote instance case, it did work). So the fix is to handle the case where the target is a cluster in BaseManager.getSharedClasspath. Will check in fix soon after the code is reviewed.
        Hide
        Hong Zhang added a comment -

        Checked in fix to v2.1 FCS branch (v2.1 FCS build 42).

        Show
        Hong Zhang added a comment - Checked in fix to v2.1 FCS branch (v2.1 FCS build 42).
        Hide
        Hong Zhang added a comment -

        Also checked in the fix to beta branch.

        Show
        Hong Zhang added a comment - Also checked in the fix to beta branch.
        Hide
        stefanvahlgren added a comment -

        Official delivery b37e contains the fix. It works now!

        Show
        stefanvahlgren added a comment - Official delivery b37e contains the fix. It works now!

          People

          • Assignee:
            prasads
            Reporter:
            stefanvahlgren
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: