The release includes ControlTier installer, Antdepo client and Commander extension enhancements that allow a clear distinction to be drawn between the meaning and use of node object names and their "hostname" attribute value.
Until this release, it has been the convention for the "client.hostname" property used by the installer to be used to set:
- The "framework.node" property value for Antdepo
- The Node object name registered by depot-setup
- The Node object's "hostname" attribute also set by depot-setup in the project
- "client.hostname" is used to set "framework.node" and the Node object's "hostname" attribute.
- A new installer property, "client.node.name", is used to set the Node object name.
Drawing this distinction has a number of benefits.
From the project perspective, it is now possible to register Node objects with logically relevant names. i.e. Instead of a Node object being named using the (possibly user name qualified) network host name used to access it (e.g. "prd@w01d02.company.com"), it can use an application centric functional name (e.g. "web-server-01", or "build-box", etc).
A second benefit - and the one that really drove the timing of this change - is that it was difficult to exploit the "user@host" support introduced for "client.hostname" with 3.1 since the ProjectBuilder object XML ("projectxml") needs to translate all object names into XML element names as part of the "load-objects" command, and XML does not support element names that include the "@" character.
Thus, you can see that this enhancement tidies up a loose end in the 3.1 functionality. (Note that theses ideas are going to be further enhanced and extended under 3.2).
Here's a practical example of taking a single node (called "development") and installing the ControlTier server under one account ("anthony"), and establishing two client installations on the same system under separate accounts ("user1" and "user2").
The three "default.properties" files are setup as follows:
[anthony@development ControlTier-3.1]$ diff default.properties default.properties.orig(Note that in all cases the "server.tomcat.hostname" is setup to the host name of the ControlTier server system - no user name qualification required of course).
31c31
< server.tomcat.hostname = development
---
> server.tomcat.hostname = localhost
98c98
< client.hostname = anthony@development
---
> client.hostname = ${server.tomcat.hostname}
103c103
< client.node.name = server
---
> client.node.name = ${server.tomcat.hostname}
[user1@development ControlTier-3.1]$ diff default.properties default.properties.orig
31c31
< server.tomcat.hostname = development
---
> server.tomcat.hostname = localhost
98c98
< client.hostname = user1@development
---
> client.hostname = ${server.tomcat.hostname}
103c103
< client.node.name = client-1
---
> client.node.name = ${server.tomcat.hostname}
[user2@development ControlTier-3.1]$ diff default.properties default.properties.orig
31c31
< server.tomcat.hostname = development
---
> server.tomcat.hostname = localhost
98c98
< client.hostname = user2@development
---
> client.hostname = ${server.tomcat.hostname}
103c103
< client.node.name = client-2
---
> client.node.name = ${server.tomcat.hostname}
With the installer configured this way, Node objects are registered in Workbench as follows:
Finally, note how node object attributes can be subsequently updated using object XML, in this example setting custom descriptions:<?xml version="1.0"?>Anthony Shortland.
<!DOCTYPE project PUBLIC "-//ControlTier Software Inc.//DTD Project Document 1.0//EN" "project.dtd">
<project>
<node type="Node" name="server" description="ControlTier server node" hostname="anthony@development"/>
<node type="Node" name="client-1" description="ControlTier client node" hostname="user1@development"/>
<node type="Node" name="client-2" description="ControlTier client node" hostname="user2@development"/>
</project>
anthony@controltier.com