Bug 7045 - Make Nimbus services installation portable
: Make Nimbus services installation portable
: Nimbus
Workspace service
: 2.4
: PC Linux
: P3 normal
: 2.5
Assigned To:
: 7013 7046
  Show dependency treegraph
Reported: 2010-06-09 14:52 by
Modified: 2010-06-19 23:17 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2010-06-09 14:52:44
Currently the installation system will copy the absolute path of the target
directory into various configurations that the service uses to find files,
databases, etc.  This means that when you move the directory, everything needs
to be changed "manually."

Instead, Nimbus could use a special token that meant "NIMBUS_HOME"

When Spring intakes the configuration, we could intercept and switch in the
right value.  Administrators that went outside NIMBUS_HOME would be on their

This is more valuable than it might seem at first, it allows for easy "non
unit" testing via programmatic creation and teardown of databases etc. without
messing with configuration files.
------- Comment #1 From 2010-06-09 15:53:21 -------
Merged the work for this in 'relpath' branch to master.

$ ./bin/install /tmp/nimbus-relpath
$ /tmp/nimbus-relpath/bin/nimbusctl start
# start a VM here ... 
$ /tmp/nimbus-relpath/bin/nimbusctl stop
$ mv /tmp/nimbus-relpath /tmp/nimbus-newpath
$ cd /tmp/nimbus-newpath
$ ./bin/nimbus-configure
$ /tmp/nimbus-newpath/bin/nimbusctl start
# kill a VM here ... 

We will need to discuss how this could work with cumulus installed.


Remember you do need to stop the services container first :-)
------- Comment #2 From 2010-06-14 09:06:21 -------
This resulted in a regression with something in the code expecting a String
rather than an instance of Resource and the testing so far did not catch it.

Thankyou Pierre for finding and fixing this!

------- Comment #3 From 2010-06-14 09:31:28 -------
Looked over the rest of the changes like that, I don't see this problem
cropping up.  Something to be aware of.

I think the strategy of intaking a Resource instance and storing only the path
is probably the best strategy in most cases (always with a null check on the
String in case set was never called at all).


public void setSpringConfigResource(Resource springConfigResource) throws
IOException {

    this.springConfig = springConfigResource.getFile().getAbsolutePath();