Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2827

Cannot create new server after STS upgrade

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.9.2.RELEASE
    • Fix Version/s: 3.0.0.RELEASE
    • Component/s: SERVER
    • Labels:
    • Environment:

      Linux (Ubuntu 11.10) with Oracle JDK 1.6.0_32

      Description

      I had been running an earlier version of STS and had a tc Server instance.
      I deleted my old STS install. I installed 2.9.2.RELEASE and started it, opening my existing workspace.

      I deleted my tc Server instance. I tried to create a new tc Server instance
      via Servers -> New but there are no templates, so the wizard cannot complete. There was no indication of a configuration error.

      If I try this in a new (clean) workspace, I can delete and add
      tc Server instance.

      The server definition in my Window -> Preferences -> Server -> Runtime Environments was old - it
      had the old tcServer from a previous (2.9.1.FINAL) install of STS (tc Server 2.6.4 instead of 2.7.0).

      I edited my runtime environment to point to my current STS install,
      and now it now works.

      Perhaps the STS server plugin should ensure that Server Runtime Environments contains the bundled tc Server - otherwise upgrades such as mine (using an existing workspace) may fail. It's probably rare - requires manually deleting the server from the Servers view - but possible.

      (at a minimum, since this bug report exists, folks can find the workaround)

        Activity

        Hide
        Kaitlin Sherwood (c) added a comment -

        Here is what I think happened.

        The STS release has four things in it, in a directory structure like this:

        • springsource
          • apache-maven-releaseNumber1
          • spring-roo-releaseNumber2
          • sts-releaseNumber3
          • vfabric-tc-server-developer-releaseNumber4

        where releaseNumberN is the release number of one of the sub-products.

        I bet you deleted the top level – everything under "springsource". Unfortunately, vfabric-tc-server-developer is where the server templates are stored, so you blew away the server templates.

        One thing you (or people who come to this bug report wonder what happened) can do is on the very first page of the New Server Wizard is to click on the "Configure runtime" hyperlink. Selecting the old runtime environment should show a warning message in red at the bottom. Press the Edit button, and you can then select a new vfabric directory (which will probably be a sibling directory to where your STS executable is).

        I will put a check into the first page of the wizard to see if the default runtime environment still exists.

        Show
        Kaitlin Sherwood (c) added a comment - Here is what I think happened. The STS release has four things in it, in a directory structure like this: springsource apache-maven-releaseNumber1 spring-roo-releaseNumber2 sts-releaseNumber3 vfabric-tc-server-developer-releaseNumber4 where releaseNumberN is the release number of one of the sub-products. I bet you deleted the top level – everything under "springsource". Unfortunately, vfabric-tc-server-developer is where the server templates are stored, so you blew away the server templates. One thing you (or people who come to this bug report wonder what happened) can do is on the very first page of the New Server Wizard is to click on the "Configure runtime" hyperlink. Selecting the old runtime environment should show a warning message in red at the bottom. Press the Edit button, and you can then select a new vfabric directory (which will probably be a sibling directory to where your STS executable is). I will put a check into the first page of the wizard to see if the default runtime environment still exists.
        Hide
        Kaitlin Sherwood (c) added a comment -

        It looks like the validation of the runtime environment happens up in the WTP code, which we do not control. Putting a check lower down, in the STS code, looks like the wrong way to do it.

        I have opened a bug
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=387441
        asking the WTP team to improve the validation checks.

        Show
        Kaitlin Sherwood (c) added a comment - It looks like the validation of the runtime environment happens up in the WTP code, which we do not control. Putting a check lower down, in the STS code, looks like the wrong way to do it. I have opened a bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=387441 asking the WTP team to improve the validation checks.

          People

          • Assignee:
            Kaitlin Sherwood (c)
            Reporter:
            David Biesack
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: