dm Server Tools
  1. dm Server Tools
  2. DMST-107

As a user I would like to (re)start the dmServer with the -clean option from the tool suite.

    Details

    • Type: Story Story
    • Status: Done Done
    • Priority: Minor Minor
    • Resolution: Complete
    • Fix Version/s: None
    • Labels:
      None

      Description

      There appears to be no way to invoke a dmServer from STS (with DMS Tools) clearing the state (i.e. as if invoked with the -clean option).
      This appears to have been raised (over the Clean option on the server context menu) before DMST-102, but closed without change to the tools.
      STS-68 also refers to this.
      It is possible to do a clean start over AMS, so why not from STS?

        Issue Links

          Activity

          Hide
          Christian Dupuis added a comment -

          This request is being tracked in:

          STS-68: Launching server using clean argument
          https://issuetracker.springsource.com/browse/STS-68

          That is why DMST-102 has been marked duplicate.

          As a work-around you can always put the -clean argument into the program arguments of the launch configuration.

          Show
          Christian Dupuis added a comment - This request is being tracked in: STS-68 : Launching server using clean argument https://issuetracker.springsource.com/browse/STS-68 That is why DMST-102 has been marked duplicate. As a work-around you can always put the -clean argument into the program arguments of the launch configuration.
          Hide
          Christian Dupuis added a comment -

          Steve, I've added a configuration section on the server editor to enable -clean.

          On dm Server 1.0.x this will add -Dcom.springsource.server.clean=true flag; on 2.0 additionally the -Fosgi.clean=true flag will be added.

          Is that all that needs to be done? How can I verify that this is causing a clean start?

          Christian

          Show
          Christian Dupuis added a comment - Steve, I've added a configuration section on the server editor to enable -clean. On dm Server 1.0.x this will add -Dcom.springsource.server.clean=true flag; on 2.0 additionally the -Fosgi.clean=true flag will be added. Is that all that needs to be done? How can I verify that this is causing a clean start? Christian
          Hide
          Christian Dupuis added a comment -

          I noticed the following in the startup.sh of dm server 2.0:

          if [ "$CLEAN_FLAG" ]
          then
          	rm -rf $SERVER_HOME/work
          	rm -rf $SERVER_HOME/serviceability
          	APP_OPTS=" \
          		$APP_OPTS \
          		-Dcom.springsource.server.clean=true"
          
          	LAUNCH_OPTS="$LAUNCH_OPTS -Fosgi.clean=true"
          fi
          
          

          I'm not deleting the directories. Is that required?

          Show
          Christian Dupuis added a comment - I noticed the following in the startup.sh of dm server 2.0: if [ "$CLEAN_FLAG" ] then rm -rf $SERVER_HOME/work rm -rf $SERVER_HOME/serviceability APP_OPTS=" \ $APP_OPTS \ -Dcom.springsource.server.clean= true " LAUNCH_OPTS= "$LAUNCH_OPTS -Fosgi.clean= true " fi I'm not deleting the directories. Is that required?
          Hide
          Steve Powell (c) added a comment - - edited

          Christian, You can tell fairly easily if a standard dmServer starts cleanly or not by the way it announces the splash, admin, and hosted repository web apps. If it says they are already deployed then it was NOT a clean start; if it processes the INITIAL event by itself and deploys them during startup, then it is a clean start.

          E.g.
          <SPDE0048I> Processing 'INITIAL' event for file 'com.springsource.server.splash-2.0.0.D-20090707151536.war'.
          <SPDE0031I> File 'com.springsource.server.splash-2.0.0.D-20090707151536.war' already deployed.
          => NOT clean

          and
          <SPDE0048I> Processing 'INITIAL' event for file 'com.springsource.server.splash-2.0.0.D-20090707151536.war'.
          => clean

          at least in the normal case out of the box. You can use this for spot checking.

          The APP_OPTS system property setting does (virtually) nothing, and is merely used for information in dm Server. In particular, it does NOT cause a clean start. You need not set it if you don't want.

          A Clean start is caused/forced when the state cannot be recovered from work/, so that the deletion of the work/ directory is what is triggering the clean start here. The setting -Fosgi.clean=true is also necessary (at the moment) to ensure that OSGi starts cleanly (before we start in it).

          It might be nice to have an option to clear out the directories (forcing a clean start next time), but only if the option -Fosgi.clean=true can be supplied on the next launch as well. We need the osgi framework to be cleaned so we can run cleanly within it.

          It would be nice to have clean start precipitated by configuration somewhere; but this is a way off I think.

          Can you manage within these parameters?

          Show
          Steve Powell (c) added a comment - - edited Christian, You can tell fairly easily if a standard dmServer starts cleanly or not by the way it announces the splash, admin, and hosted repository web apps. If it says they are already deployed then it was NOT a clean start; if it processes the INITIAL event by itself and deploys them during startup, then it is a clean start. E.g. <SPDE0048I> Processing 'INITIAL' event for file 'com.springsource.server.splash-2.0.0.D-20090707151536.war'. <SPDE0031I> File 'com.springsource.server.splash-2.0.0.D-20090707151536.war' already deployed. => NOT clean and <SPDE0048I> Processing 'INITIAL' event for file 'com.springsource.server.splash-2.0.0.D-20090707151536.war'. => clean at least in the normal case out of the box. You can use this for spot checking. The APP_OPTS system property setting does (virtually) nothing, and is merely used for information in dm Server. In particular, it does NOT cause a clean start. You need not set it if you don't want. A Clean start is caused/forced when the state cannot be recovered from work/, so that the deletion of the work/ directory is what is triggering the clean start here. The setting -Fosgi.clean=true is also necessary (at the moment) to ensure that OSGi starts cleanly (before we start in it). It might be nice to have an option to clear out the directories (forcing a clean start next time), but only if the option -Fosgi.clean=true can be supplied on the next launch as well. We need the osgi framework to be cleaned so we can run cleanly within it. It would be nice to have clean start precipitated by configuration somewhere; but this is a way off I think. Can you manage within these parameters?
          Hide
          Christian Dupuis added a comment -

          Steve, thanks for the detailed instructions. That helped me to implement this feature.

          I added a the program and VM arguments for dm Server 1.0.x and 2.0.x as well as deletion of the work and serviceability directories. There is also a configuration option to enable -clean on the server editor now.

          You can install this from the nightly update site and give it a try.

          Christian

          Show
          Christian Dupuis added a comment - Steve, thanks for the detailed instructions. That helped me to implement this feature. I added a the program and VM arguments for dm Server 1.0.x and 2.0.x as well as deletion of the work and serviceability directories. There is also a configuration option to enable -clean on the server editor now. You can install this from the nightly update site and give it a try. Christian

            People

            • Assignee:
              Unassigned
              Reporter:
              Steve Powell (c)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                First Response Date: