Initial commit for cassandra-bundle module

The cassandra-bundle module packages a bundle recipe for provisioning machines
with instances of Cassandra.

Conflicts:

	modules/common/pom.xml
Install rhq cassandra bundle on server start up.

This commit introduces a number of changes in order to support installing the
rhq cassandra bundle on start up. The contents of the build artifact for the
cassandra-bundle module has changed. The JAR file itself is no longer the
bundle. The artifact now consists of two files - the bundle zip file and
a new file cassandra.properties. cassandra.properties will provide deployment
options like the number of nodes in the cluster.

The bundle recipe file, deploy.xml, is now filtered at build time with
cassandra.properties. Attribute values in deploy.xml for things like
the bundle name and bundle version have to be the same as the ones used in
the installBundle method. Filtering with cassandra.properties makes this
possible.

StartupServlet has been updated to invoke CassandraClusterManagerBean.installBundle.
The installBundle method is idempotent. It will install the necessary bundle
components only if they do not already exist in the database. It can be invoked
multiple times without having any additional effect.

Conflicts:

	modules/enterprise/server/jar/pom.xml
	modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/core/StartupBean.java
	modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/util/LookupUtil.java
Refactoring logic for embedded cluster deployment

This is the initial commit for EmbeddedDeployer. It performs deployment of an
embedded cluster which is the default cluster type for development. An embedded
cluster is one in which all nodes run on localhost and are bound aliases of the
loopback address, e.g., 127.0.0.2, 127.0.0.3, etc.

EmbeddedDeployer does not server APIs to deploy the cluster. More specifically,
it does not use the bundles subsystem. It does however use the Ant-based
bundles APIs to deploy the cassandra bundle. Since it does not use server APIs
which require a running agent to carry out requests, EmbeddedDeployer is
suitable for bootstrapping scenarios.

EmbeddedDeployer looks for the presence of a marker file named .installed in
the cluster directory for installing nodes. If that file exists, it assumes
that the cluster is already is installed and does not do any installation.
If the marker file is not present, anything in the cluster directory is purged
and nodes will be provisioned.

Conflicts:

	modules/enterprise/server/jar/pom.xml
	modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/core/StartupBean.java
Periodically check that we can connect to at least one cassadra node

This is the initial commit for CassandraClusterHeartBeatJob. It checks that the
RHQ server can connect to at least one cassandra node. If the server cannot
establish a connection to any nodes, the rhq server goes into maintenance mode.
When in maintenance mode the server will be brought back into normal operating
mode when a connection is established.

CassandraClusterManagerBean submits the jobs in its installBundle method which
is called at server start up. EmbeddedDeployer has been updated to return a
list of cluster ndoes. That list is passed into CassandraClusterHeartBeatJob.

Conflicts:

	modules/enterprise/server/jar/pom.xml
Need to parameterize the listen_address and rpc_address properties in bundle recipe

When I first set up this module I forgot to parameterize the listen_address and
rpc_address properties in cassandra.yaml. In the server plugin prototype
project, I set both of them to the hostname bundle recipe property. This commit
introduces separate listen.address and rpc.address bundle recipe properties
making it possible to bind to different interfaces.
Changing deployment property cluster.type property to is-embedded

After having thought more about the differnet deployment scenarios, I think we
will have either embedded or non-embeeded clusters. A boolean makes more sense
in this case.
fix dev profile to copy artifact to correct location
Start nodes after they are installed on the file system

This commit adds logic for starting nodes as part of the bootstrapping process.
An option may be added in a future commit to turn off automatically starting
nodes.
Install schema after starting first node

After starting the first node we wait until we can establish a connection to it
in order to verify that it is running. If we cannot connect after 10 attempts,
an exception is thrown. Once a connection is established, we execute
cassandra-cli on dbsetup.script.

There is still a lot more work to do here like better error handling, logging,
etc.
Include JNA libraries in cassandra bundle and make logging configurable

The cassandra bundle now includes JNA libraries with this commit. As described
here, http://www.datastax.com/docs/1.1/install/install_jre, JNA should be
installed for production use. The logging level is now parameterized in the
bundle recipe and configurable via cassandra.properties with the
rhq.cassandra.logging.level property.

This commit also includes some debug changes the updateSchema method in
EmbeddedDeployer.
adding work around for snappy-java library with Java 7

Cassandra uses snappy-java, a library for the snappy compressor. It uses a
native library. That library fails to load in Cassandra when running on Mac
OS X with Java 7 due to https://github.com/xerial/snappy-java/issues/6. This
issue is fixed in newer versions of snappy-java. This commit adds a profile
that is activated when running on Mac OS X and that upgrades the version
of snappy-version in the cassandra bundle so that the snappy compressor can
still be used during development/testing.
Initial commit for cassandra-common-itests

This is the first, long overdue commit for an integration tests module. So far
there is a single test that stands up a two node cluster and verifies that the
schema propagates across the cluster.

EmbeddedDeployer.waitForNodeToStart has been refactored slightly. It now sleeps
for a second after a failed connection attempt. I suspect that my forgetting
to add it before may have contributed to some of the failed schema installs.
rename module directory to cassandra-common

cassandra-common makes more sense than cassandra-bundle since the module now
contains things beyond the cassandra bundle.
Initial commit for server-metrics module

MetricsServer.java is starting out as a port from the code in
https://github.com/jsanda/rhq-metrics-plugins.
fixing cassandra version

we should be on 1.1.5 which is the latest release.
Initial commit for MetricsServerTest

This commit includes a test for inserting multiple raw metrics. This commit
also straightens out some SLF4J dependency conflicts.
Initial commit for ClusterInitService

ClusterInitiService provides methods for use during cluster initialization. It
currently provides methods to block until the cluster is initialized and
accepting client connections and another method that blocks until schema
agreement is reached.
using ClusterInitService to wait for cluster initialization

ClusterInitService provides a more robust way (than sleeping for some arbitrary
time) to ensure that the cluster has reached a consistent state before
executing tests.
Porting code from github repo for calculating aggregates

This commit is a port of code from the https://github.com/jsanda/rhq-metrics-plugins
repo. It adds the calculateAggregates method to MetricsServer along with
accompanying tests. I am currently seeing a failure in
MetricsServerTest.calculateAggregatesForOneScheduleWhenDBIsEmpty.
fixing calculateAggregatesForOneScheduleWhenDBIsEmpty test

calculateAggregatesForOneScheduleWhenDBIsEmpty was using timestamps based off
of the current time which could lead to inconsistent results when executing
around boundary times for the 6 hour bucket. The test has been refactored to
use timestamps based off of set hours. The metric data that is inserted during
the test always has timestamps in the fifth hour (of the day).