activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chir...@apache.org
Subject svn commit: r1052062 [2/2] - in /activemq/activemq-apollo/trunk: apollo-bdb/src/main/scala/org/apache/activemq/apollo/broker/store/bdb/dto/ apollo-bdb/src/test/resources/org/apache/activemq/apollo/broker/store/bdb/dto/ apollo-broker/src/main/resources/...
Date Wed, 22 Dec 2010 20:46:07 GMT
Modified: activemq/activemq-apollo/trunk/apollo-website/src/documentation/user-manual.md
URL: http://svn.apache.org/viewvc/activemq/activemq-apollo/trunk/apollo-website/src/documentation/user-manual.md?rev=1052062&r1=1052061&r2=1052062&view=diff
==============================================================================
--- activemq/activemq-apollo/trunk/apollo-website/src/documentation/user-manual.md (original)
+++ activemq/activemq-apollo/trunk/apollo-website/src/documentation/user-manual.md Wed Dec
22 20:46:05 2010
@@ -78,9 +78,9 @@ single connector.
 {pygmentize:: xml}
 <broker id="default" xmlns="http://activemq.apache.org/schema/activemq/apollo">
 
-  <virtual-host id="default">
-    <host-name>localhost</host-name>
-  </virtual-host>
+  <virtual_host id="default">
+    <host_name>localhost</host_name>
+  </virtual_host>
 
   <connector id="tcp" bind="tcp://0.0.0.0:61613"/>
   
@@ -113,13 +113,13 @@ A `connector` element can be configured 
    supported protocols can connect via this transport.
 
 Furthermore, the connector element may contain protocol specific
-configuration elements. For example, to add have the broker set the `user-id`
+configuration elements. For example, to add have the broker set the `user_id`
 header of messages to the id of user that sent the message, you would
 use the following configuration:
 
 {pygmentize:: xml}
 <connector id="tcp" bind="tcp://0.0.0.0:61613">
-  <stomp add-user-header="user-id"/>
+  <stomp add_user_header="user_id"/>
 </connector>
 {pygmentize}
 
@@ -131,27 +131,27 @@ persistence, security, and runtime const
 
 Protocols like STOMP 1.1, inform the broker of which host the client is
 attempting to connect with. The broker will search it's list of virtual hosts
-to find the first host who has a configured `host-name` that matches.
+to find the first host who has a configured `host_name` that matches.
 Protocols which do NOT support virtual hosts, will just connect to the first
 virtual host defined in the configuration file.
 
-* `host-name` : a host name that the virtual host is known as.  This element
+* `host_name` : a host name that the virtual host is known as.  This element
   should be repeated multiple times if the host has many host names.
 
-A `virtual-host` element may be configured with the following attributes:
+A `virtual_host` element may be configured with the following attributes:
 
 * `enabled` : if set to false, then the virtual host will be disabled.
 
 * `purge_on_startup` : if set to true, the persistent state of the broker
    will be purged when the broker is started up.
 
-The `virtual-host` can also define multiple `destination` and `queue` 
+The `virtual_host` can also define multiple `destination` and `queue` 
 elements to secure or tune how message delivery works for different 
 destinations or queues.  If none are defined, then sensible 
 default settings are used which allow queue and destinations to be
 auto created as they get accessed by applications.
 
-Finally `virtual-host` configuration should also include a message store
+Finally `virtual_host` configuration should also include a message store
 configuration element to enable message persistence on the virtual host.
 
 ##### Destinations
@@ -193,20 +193,20 @@ are:
 * `kind` : Valid valuest are `ptp` for standard
   point to point queues or `ds` for durable subscriptions.
 
-* `client-id` : Valid only if the `kind` is `ds`. This specify which client
+* `client_id` : Valid only if the `kind` is `ds`. This specify which client
   id this configuration should match.
 
-* `subscription-id` : Valid only if the `kind` is `ds`. This specify which subscription
+* `subscription_id` : Valid only if the `kind` is `ds`. This specify which subscription
   id this configuration should match.
 
 A `queue` element may be configured with the following attributes:
 
-* `queue-buffer` : The amount of memory buffer space allocated for each queue.
+* `queue_buffer` : The amount of memory buffer space allocated for each queue.
 
-* `producer-buffer` : The amount of memory buffer space allocated to each
+* `producer_buffer` : The amount of memory buffer space allocated to each
 producer for receiving messages.
 
-* `consumer-buffer` : The amount of memory buffer space allocated to each
+* `consumer_buffer` : The amount of memory buffer space allocated to each
 subscription for receiving messages.
 
 * `persistent` : If set to false, then the queue will not persistently
@@ -215,7 +215,7 @@ store it's message.
 * `swap` : If set to false, then the queue will not swap messages out of 
 memory.
 
-* `flush-range-size` : The number max number of flushed queue entries to load
+* `flush_range_size` : The number max number of flushed queue entries to load
   from the store at a time. Note that Flushed entires are just reference
   pointers to the actual messages. When not loaded, the batch is referenced
   as sequence range to conserve memory.
@@ -265,20 +265,20 @@ For those of you with curl installed, yo
 
     curl http://download.oracle.com/maven/com/sleepycat/je/4.1.6/je-4.1.6.jar > ${APOLLO_HOME}/lib/je-4.1.6.jar
 
-Once that is done, you can enable the store by adding a `bdb-store` element
-inside your `virtual-host`.  Example:
+Once that is done, you can enable the store by adding a `bdb_store` element
+inside your `virtual_host`.  Example:
     
 {pygmentize:: xml}
   ...
-  <virtual-host id="default">
+  <virtual_host id="default">
     ...
-    <bdb-store directory="${apollo.base}/data"/>
+    <bdb_store directory="${apollo.base}/data"/>
     ..
-  </virtual-host>
+  </virtual_host>
   ...
 {pygmentize}
 
-A `bdb-store` element may be configured with the following attributes:
+A `bdb_store` element may be configured with the following attributes:
 
 * `directory` : The directory which the store will use to hold it's data
   files. The store will create the directory if it does not already
@@ -298,20 +298,20 @@ The problem is that it is still unstable
 if your willing to dive in with a debugger to help solidify the 
 implementation.
 
-You can enable the store by adding a `hawtdb-store` element
-inside your `virtual-host`.  Example:
+You can enable the store by adding a `hawtdb_store` element
+inside your `virtual_host`.  Example:
     
 {pygmentize:: xml}
   ...
-  <virtual-host id="default">
+  <virtual_host id="default">
     ...
-    <hawtdb-store directory="${apollo.base}/data"/>
+    <hawtdb_store directory="${apollo.base}/data"/>
     ..
-  </virtual-host>
+  </virtual_host>
   ...
 {pygmentize}
 
-A `hawtdb-store` element may be configured with the following attributes:
+A `hawtdb_store` element may be configured with the following attributes:
 
 * `directory` : The directory which the store will use to hold it's data
   files. The store will create the directory if it does not already
@@ -328,29 +328,29 @@ A `hawtdb-store` element may be configur
 ${project_name} supports SSL/TLS for transport level security to avoid 3rd
 parties listening in on the communications between the broker and it's
 clients. To enable it, you just need to add a connector which uses the `ssl`
-or `tls` transport and add a `key-storage` configuration element under the
+or `tls` transport and add a `key_storage` configuration element under the
 `broker` to configure the where the encryption keys and certificates are
 stored.
 
 Example:
 {pygmentize:: xml}
   ...
-  <key-storage 
+  <key_storage 
      file="${apollo.base}/etc/keystore" 
      password="password" 
-     key-password="password"/>
+     key_password="password"/>
   <connector id="tls" bind="tls://0.0.0.0:61614"/>
   ...
 {pygmentize}
 
-The attributes that you can configure on the `key-storage` element are:
+The attributes that you can configure on the `key_storage` element are:
 
 * `file` : Path to where the key store is located.
 * `password` : The key store password
-* `key-password` : The password to the keys in the key store.
-* `store-type` : The type of key store, defaults to `JKS`.
-* `trust-algorithm` : The trust management algorithm, defaults to `SunX509`.
-* `key-algorithm` : The key management algorithm, defaults to `SunX509`.
+* `key_password` : The password to the keys in the key store.
+* `store_type` : The type of key store, defaults to `JKS`.
+* `trust_algorithm` : The trust management algorithm, defaults to `SunX509`.
+* `key_algorithm` : The key management algorithm, defaults to `SunX509`.
 
 #### Authentication
 
@@ -359,7 +359,7 @@ ${project_name} configurations use file 
 is performed using JAAS who's config file is located in the instance
 directory under `etc/login.conf`. JAAS configuration files can define
 multiple named authentication domains. The `broker` element and
-`virtual-host` elements can be configured to authenticate against these
+`virtual_host` elements can be configured to authenticate against these
 domains.
 
 The `authentication` element defined at the broker level will get used to 
@@ -372,19 +372,19 @@ to `false`.
 <broker id="default" xmlns="http://activemq.apache.org/schema/activemq/apollo">
   <authentication domain="internal"/>
   
-  <virtual-host id="wine.com">
+  <virtual_host id="wine.com">
     <authentication domain="external"/>
-    <host-name>wine.com</host-name>
-  </virtual-host>
+    <host_name>wine.com</host_name>
+  </virtual_host>
 
-  <virtual-host id="internal.wine.com">
-    <host-name>internal.wine.com</host-name>
-  </virtual-host>
+  <virtual_host id="internal.wine.com">
+    <host_name>internal.wine.com</host_name>
+  </virtual_host>
 
-  <virtual-host id="test">
+  <virtual_host id="test">
     <authentication enabled="false"/>
-    <host-name>cheeze.com</host-name>
-  </virtual-host>
+    <host_name>cheeze.com</host_name>
+  </virtual_host>
 
   <connector id="tcp" bind="tcp://0.0.0.0:61613"/>
 </broker>
@@ -411,13 +411,13 @@ lists (ACLs). 
 
 The default user principal class recognized is
 `org.apache.activemq.jaas.UserPrincipal`. You can configure it by adding
-`user-principal-kind` elements under the `authentication` element. The first
+`user_principal_kind` elements under the `authentication` element. The first
 principal who's type matches this list will be selected as the user's
 identity for informational purposes.
 
 Similarly, default acl principal class recognized is
 `org.apache.activemq.jaas.GroupPrincipal`. You can configure it by adding
-`acl-principal-kinds elements under the `authentication` element. The ACL
+`acl_principal_kinds elements under the `authentication` element. The ACL
 entries which do not have an explicit kind will default to using the the
 kinds listed here.
 
@@ -426,10 +426,10 @@ Example of customizing the principal kin
 {pygmentize:: xml}
   ...
   <authentication domain="apollo">
-    <user-principal-kind>com.sun.security.auth.UnixPrincipal</user-principal-kind>
-    <user-principal-kind>com.sun.security.auth.LdapPrincipal</user-principal-kind>
-    <acl-principal-kind>com.sun.security.auth.UnixPrincipal</acl-principal-kind>
-    <acl-principal-kind>com.sun.security.auth.LdapPrincipal</acl-principal-kind>
+    <user_principal_kind>com.sun.security.auth.UnixPrincipal</user_principal_kind>
+    <user_principal_kind>com.sun.security.auth.LdapPrincipal</user_principal_kind>
+    <acl_principal_kind>com.sun.security.auth.UnixPrincipal</acl_principal_kind>
+    <acl_principal_kind>com.sun.security.auth.LdapPrincipal</acl_principal_kind>
   </authentication>
   ...
 </broker>
@@ -439,7 +439,7 @@ Example of customizing the principal kin
 
 User authorization to broker resources is accomplished by configuring an
 access control list using an `acl` element on the `broker`, `connector`,
-`virtual-host`, `destination`, or `queue` resources. The acl defines which
+`virtual_host`, `destination`, or `queue` resources. The acl defines which
 principals are allowed or denied access to perform actions against the
 resources.  An example of `acl` is shown below:
 
@@ -460,7 +460,7 @@ access to a user principal. The special 
 Users can have many principals of many different kinds associated with
 them. The rules will only match up against principals of type
 `org.apache.activemq.jaas.GroupPrincipal` since that is the default
-setting of the `acl-principal-kind` of the `authentication` domain.
+setting of the `acl_principal_kind` of the `authentication` domain.
 
 If you want the rule to match against more/different kinds of principals,
 you should update the `authentication` element's configuration or you
@@ -506,13 +506,13 @@ can be secured on which resources:
 
 * `broker`
   * `admin` : use of the administrative web interface
-* `connector` and `virtual-host`
+* `connector` and `virtual_host`
   * `connect` : allows connections to the connector or virtual host
 * `destination` and `queue`
   * `create` : allows the destination or queue to be created.
   * `destroy` : allows the destination or queue to be created.
   * `send` : allows the user to send to the destination or queue
-  * `receive` : allows the user to send to do non-destructive read 
+  * `receive` : allows the user to send to do non_destructive read 
     from the destination or queue
 * `queue`
   * `consume` : allows the user to do destructive reads against the queue.
@@ -526,15 +526,15 @@ defined there. Any of the properties val
 `etc/apollo.xml.properties` can be replaced with encrypted versions by
 using the `apollo encrypt` command.
 
-Lets say you your current `key-storage` contains plain text passwords that
+Lets say you your current `key_storage` contains plain text passwords that
 need to be replaced with encrypted versions:
 
 {pygmentize:: xml}
   ...
-  <key-storage 
+  <key_storage 
      file="${apollo.base}/etc/keystore" 
      password="open" 
-     key-password="sesame"/>
+     key_password="sesame"/>
   ...
 {pygmentize}
 
@@ -562,10 +562,10 @@ text passwords with variable references 
 
 {pygmentize:: xml}
   ...
-  <key-storage 
+  <key_storage 
      file="${apollo.base}/etc/keystore" 
      password="${store.pass}" 
-     key-password="${key.pass}"/>
+     key_password="${key.pass}"/>
   ...
 {pygmentize}
 
@@ -586,19 +586,19 @@ perform basic authentication and will on
 which are in the admin ACL.
 
 If you want to change the port or the interface it binds on or perhaps
-even disable it altogether, then you should add a `web-admin`
+even disable it altogether, then you should add a `web_admin`
 configuration element inside the `broker` element to change the
 default settings. For example:
 
 {pygmentize:: xml}
 <broker ...>
   ...
-  <web-admin host="127.0.0.1" port="8001"/>
+  <web_admin host="127.0.0.1" port="8001"/>
   ...
 </broker>
 {pygmentize}
 
-A `web-admin` element may be configured with the following attributes:
+A `web_admin` element may be configured with the following attributes:
 
 * `host` : The amount of memory buffer space allocated for each queue.
 * `port` : The amount of memory buffer space allocated to each
@@ -684,7 +684,7 @@ Example STOMP frame to connect to the br
 STOMP 1.0 clients do specify which virtual host they are connecting to so
 the broker connects those clients to the first virtual host defined in
 it's configuration.  STOMP 1.1 clients do specify a virtual host when they 
-connect.  If no configured virtual host `host-name` matches the client's 
+connect.  If no configured virtual host `host_name` matches the client's 
 requested host, the connection is terminated with an ERROR.  Therefore,
 it is critical that the virtual hosts configuration define all the 
 possible host names that clients may connect to host with.



Mime
View raw message