Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1.0
    • Fix Version/s: 2.2.2
    • Component/s: eclipse-plugin
    • Labels:
      None

      Description

      Periodically the tooling will receive a deployment exception (configuration already exists) when publishing updates. The user must remove the projects, manually delete from the repository, and then re-add/re-publish. Occasionally, you must restart both the tooling and the runtime in order to delete from repository.

        Activity

        Hide
        Tim McConnell added a comment -

        Part of a larger problem where the server and Eclipse get out of sync, and is most prevalent when exceptions occur, although not exclusively. Need a good use case for replicating the problem, and a better solution for keeping the GEP and the server in sync.

        Show
        Tim McConnell added a comment - Part of a larger problem where the server and Eclipse get out of sync, and is most prevalent when exceptions occur, although not exclusively. Need a good use case for replicating the problem, and a better solution for keeping the GEP and the server in sync.
        Hide
        Delos Dai added a comment -

        I think it's not just the problem of sync. If you deploy a module to G server without GEP, it may also produce a "Configuration already exist" exception. I think it's due to the problem of G server deployer. The exception is likely to be thrown in deployment if there has been a deployment happened before and failed. So the best solution for this JIRA is to let G server remove the deployed modules once they're not deployed successfully.

        So I suggest to find a scenario always producing the problem and report it to G server as a JIRA. Then, this JIRA can be closed.

        Show
        Delos Dai added a comment - I think it's not just the problem of sync. If you deploy a module to G server without GEP, it may also produce a "Configuration already exist" exception. I think it's due to the problem of G server deployer. The exception is likely to be thrown in deployment if there has been a deployment happened before and failed. So the best solution for this JIRA is to let G server remove the deployed modules once they're not deployed successfully. So I suggest to find a scenario always producing the problem and report it to G server as a JIRA. Then, this JIRA can be closed.

          People

          • Assignee:
            Tim McConnell
            Reporter:
            Tim McConnell
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development