[#HQ-306] Implement a screen for deep-dive Karaf Child Instances

Fuse HQ

HQ-146

Implement a screen for deep-dive Karaf Child Instances

Created: 05/Nov/09 04:52 PM Updated: 23/Oct/12 02:21 PM

Component/s:

Affects Version/s:

None

Fix Version/s:

4.1

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

David Grigglestone added a comment - 06/Nov/09 06:51 PM - edited

Based on feedback and ideas to date:

This screen will be attached as a sub-tab of the "Views" tab of HQ server resources of the type "KARAF" ("KARAF" is subject to change).
The sub-tab title will be "Other Instances"
Tab will display a table with a row of action buttons above
- The Karaf admin MBean ObjectName will be retrieved from the config response using the key "karafAdminName"
- Values for table will be obtained by getting the "Instances" JMX attribute
  - Note: a table row should not be created for the tabular data row that maps to the instance this server represents (compare by the "name" attribute of the object name)
Table will have following columns (obtained using CompositData key from tabular data):
- State ("State")
- Name ("Name")
- SSH Port ("Port")
- Location ("Location")
- PID ("Pid")
Action buttons:
- "Start"
  - applicable to a single selected instance [can't do multiples as the JMX API does not support it .. but should we support impression of multiples by making multiples calls to the backend?], calls the JMX operation "startInstance" with 2 params:
    - param1 = the name of the selected instance
    - param2 = a captured set of java options (e.g "-Xmx..." etc.)
- "Stop"
  - applicable to a single selected instance [can't do multiples as the JMX API does not support it .. but should we support impression of multiples by making multiples calls to the backend?], calls the JMX operation "stopInstance" with 1 params:
    - params1 = the name of the selected instance
- "Create"
  - call the JMX operation "createInstance"; but first need to prompt for the following params:
    - param1 = the name of the instance to be created
    - param2 = the SSH port number (Note that setting this port <= 0 equates to an instruction to use the next port in sequence. The UI should make this clear, as in the usual case we'd want to allow karaf itself to manage its SSH port-range.)
    - param3 = the location (Relative to <install_dir>/instances. The default is simply <install_dir>/instances/<instance_name>)
    - param4 = comma separated list of features names
    - param5 = comma separated list of feature URLs
  - Param4 and param5 don't have to match .. there isn't a one-to-one correspondence. A featuresURL effectively identifies a fragment of XML containing the definition of one or more features. The only requirement is that all the boot features are defined in some XML file identified by an installed featuresURL. So for example if the features is specified as foo,bar and both these features are defined in mvn:org.acme/foobar/x.y/xml/features, then this is only repo required on the featureURLs list.
- "Destroy"
  - applicable to a single selected instance [can't do multiples as the JMX API does not support it .. but should we support impression of multiples by making multiples calls to the backend?], calls the JMX operation "destroyInstance" with 1 params:
    - params1 = the name of the instance
- "Change Port"
  - applicable to a single selected instance [can't do multiples as the JMX API does not support it], calls the JMX operation "changePort" with 2 params:
    - param1 = the name of the instance
    - param2 = a captured SSH port
  - Cannot be executed on instances that are in a started state

[ Show » ]

David Grigglestone added a comment - 06/Nov/09 06:51 PM - edited Based on feedback and ideas to date:

This screen will be attached as a sub-tab of the "Views" tab of HQ server resources of the type "KARAF" ("KARAF" is subject to change).
The sub-tab title will be "Other Instances"
Tab will display a table with a row of action buttons above
- The Karaf admin MBean ObjectName will be retrieved from the config response using the key "karafAdminName"
- Values for table will be obtained by getting the "Instances" JMX attribute
  - Note: a table row should not be created for the tabular data row that maps to the instance this server represents (compare by the "name" attribute of the object name)
Table will have following columns (obtained using CompositData key from tabular data):
- State ("State")
- Name ("Name")
- SSH Port ("Port")
- Location ("Location")
- PID ("Pid")
Action buttons:
- "Start"
  - applicable to a single selected instance [can't do multiples as the JMX API does not support it .. but should we support impression of multiples by making multiples calls to the backend?], calls the JMX operation "startInstance" with 2 params:
    - param1 = the name of the selected instance
    - param2 = a captured set of java options (e.g "-Xmx..." etc.)
- "Stop"
  - applicable to a single selected instance [can't do multiples as the JMX API does not support it .. but should we support impression of multiples by making multiples calls to the backend?], calls the JMX operation "stopInstance" with 1 params:
    - params1 = the name of the selected instance
- "Create"
  - call the JMX operation "createInstance"; but first need to prompt for the following params:
    - param1 = the name of the instance to be created
    - param2 = the SSH port number (Note that setting this port <= 0 equates to an instruction to use the next port in sequence. The UI should make this clear, as in the usual case we'd want to allow karaf itself to manage its SSH port-range.)
    - param3 = the location (Relative to <install_dir>/instances. The default is simply <install_dir>/instances/<instance_name>)
    - param4 = comma separated list of features names
    - param5 = comma separated list of feature URLs
  - Param4 and param5 don't have to match .. there isn't a one-to-one correspondence. A featuresURL effectively identifies a fragment of XML containing the definition of one or more features. The only requirement is that all the boot features are defined in some XML file identified by an installed featuresURL. So for example if the features is specified as foo,bar and both these features are defined in mvn:org.acme/foobar/x.y/xml/features, then this is only repo required on the featureURLs list.
- "Destroy"
  - applicable to a single selected instance [can't do multiples as the JMX API does not support it .. but should we support impression of multiples by making multiples calls to the backend?], calls the JMX operation "destroyInstance" with 1 params:
    - params1 = the name of the instance
- "Change Port"
  - applicable to a single selected instance [can't do multiples as the JMX API does not support it], calls the JMX operation "changePort" with 2 params:
    - param1 = the name of the instance
    - param2 = a captured SSH port
  - Cannot be executed on instances that are in a started state