** DONE ** INFO -- jdbcURL received
------------------------------------------------
** DONE **  delete password file
------------------------------------------------
** DONE ** configure-ha-cluster called a second time -- should detect and fail earlier...
  warning logged instead of an error if the DB is pre-existing
------------------------------------------------
** DONE **  a second cluster won't work with the same portbase (15200)
------------------------------------------------
** DONE ** add configure-ha-persistence
------------------------------------------------
** DONE ** Add generic props to availability service
property:  ha-hosts
property: ha-agent-port
property: ha-db-name
------------------------------------------------
** DONE ** configure-ha-persistence doesn't need --hosts, --haagentport args...
------------------------------------------------
** DONE ** What to do -- what if they give host/port and they do NOT match what's in Config -- save the new ones?
-- answer use the commandline-specified agent - but do NOT change the persisted agent
------------------------------------------------
** DONE ** -- option #1
We need to define the semantics of configure-ha-cluster and remove-ha-cluster when the cluster's 
configuration is shared (i.e. with another cluster or unclustered instance). There are two approaches: 
        1.Do not allow create-ha-store on a cluster with a shared configuration. 
        2.Modify the shared configuration to reference only one of the hadb resources. We had chosen this approach, because it is more flexible;
          however, after thinking about this some more, I think option 1 is better. If we stick with option 2, then out of the box both clusters will
          share the same HADB (which we do not want), and informing customers how to introduce system-property tokens is painful and error
          prone. 

   com.sun.enterprise.config.serverbeans.ClusterHelper.isClusterStandAlone(ConfigContext configContext, String clusterName) 
------------------------------------------------
*** DONE AND REDONE ***   4.Introduction of the new HADB bits (coming on Friday) will require configuration of an HADB management port. This will not be stored in
     domain.xml and as such will be a new optional (since there is a well known default value) management port option to all of the HADB
     commands (create-ha-store, clear-ha-store, configure-ha-cluster, remove-ha-cluster). 
-- the ports and hosts and db-name are now stored in domain.xml -- the values are ONLY required for configure-ha-cluster now
-----------------------------------------------------------
*** DONE ****
We need to define the semantics of deleting a cluster which was configured for HA using configure-ha-cluster. There are a couple of options: 
        1.Do not allow an HA cluster to be deleted unless its corresponding ha store has been deleted. 
        2.Allow the HA cluster to be deleted. Users must be able to remove-ha-cluster on a cluster which has been deleted to later clean up the
          database. Unless issues arise, this is the approach we decided to adopt.
Implemented solution #2
------------------------------------------------
*** DONE *** We have determined that we need to keep the clear-ha-store command. We need to ensure that our create-ha-store
 and clear-ha-store have roughly the same functionality as their Hercules counterparts 
(create-session-store and clear-session-store). In looking at the table below, I
     see that we are missing some the storeuser, storepassword, and dbsystempassword options. 

Actual command:

/ee/jdk/bin/java -cp /ee/lib/appserv-se.jar:/ee/hadb/4.4-0.3/lib/hadbjdbc4.jar 
com.sun.enterprise.ee.admin.hadbmgmt.HADBSessionStoreUtil 
create 
jdbc:sun:hadb:10.5.79.47:15205,10.5.79.47:15225 
admin  (info.getDatabaseUser()) -- storeuser
adminadmin (info.getDatabasePassword()) -- storepassword
system (info.getSystemUser())
adminadmin (info.getSystemPassword())   -- dbsystempassword


------------------------------------------------
*** DONE ***
   We have decided that the DAS will not run an HADB management agent as previously thought. 
------------------------------------------------
***DONE ***   When invoking hadbm, we need to ensure that we are not passing passwords on the command line. Instead, we should be creating a
     protected, temporary password file and using the passwordfile option to hadbm. 
------------------------------------------------
*** DONE ***   After looking at the Glaucus admin guide, I have reached the conclusion that we should introduce a 
configure-ha-persistence command (see table below).
------------------------------------------------
*** DONE ***
   What happens when configure-ha-cluster is given an operand which is not a clusterName (e.g. a config name or server name)?  
This is what happens:

asadmin configure-ha-cluster --hosts iasengsol6,iasengsol6 xyz
Operation 'createHACluster' failed in 'hadb-config' Config Mbean.
Target exception message: com.sun.enterprise.config.ConfigException: Cluster xyz does not exist.
CLI137 Command configure-ha-cluster failed.

------------------------------------------------
   Finally, we need to make sure that the semantics of all these commands are well documented somewhere e.g. a functional spec. This will
     assist in testing, documentation, etc.
------------------------------------------------
*** DONE *** parse for dbpassword in parseProps()
------------------------------------------------
Document SEVERE log messages...
example:
poolmgr.datasource_error_excp=RAR5043:Error in creating data source object:
RAR5043.diag.cause.1=Exception while creating persistent manager resource.
RAR5043.diag.check.1=Check whether the persistent manager factory class is configured properly and is available in the classpath.
RAR5043.diag.check.2=Check whether the jdbc resource name is correct and is configured properly. 