QPID-2822: move documentation of the log message property files from the files themselves to a Docbook format file for inclusion in a future developer docs book

Applied patches from Sorin Suciu <ssuciu@gmail.com>


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@990146 13f79535-47bb-0310-9956-ffa450edef68

13 files changed, 274 insertions, 2291 deletions

diff --git a/qpid/doc/book/src/Java-Broker-StatusLogMessages.xml b/qpid/doc/book/src/Java-Broker-StatusLogMessages.xml
new file mode 100644
index 0000000000..663bfca5a5
--- /dev/null
+++ b/qpid/doc/book/src/Java-Broker-StatusLogMessages.xml
@@ -0,0 +1,274 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<?oxygen RNGSchema="http://www.oasis-open.org/docbook/xml/5.0/rng/docbook.rng" type="xml"?>
+<book xmlns="http://docbook.org/ns/docbook"
+    xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
+    <info>
+        <title>Operational Logging</title>
+        <author>
+            <orgname>Apache Software Foundation</orgname>
+        </author>        
+    </info>
+    <chapter>
+        <title>Status Log Messages</title>
+        <para>This file was derivied from LogMessages used within the Java Broker and originally defined on:
+           <tag xlink:href="http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages">Apache Wiki</tag></para>
+        <sect1>
+            <title>Technical Notes:</title>
+            <para>The status log messages file  is a standard Java Properties file so white space is respected at the end of
+                the lines. This file could be processed in a number of ways:</para>
+            <para>
+                <orderedlist>
+                    <listitem>
+                        <para>ResourceBundle</para>
+                        <para>This file is loaded as a ResourceBundle. The en_US addition to the
+                            file is the localisation. Additional localisations can be provided and
+                            will automatically be selected based on the &lt;locale> value in the
+                            config.xml. The default locale is en_US.</para>
+                    </listitem>
+                    <listitem>
+                        <para>MessageFormat</para>
+                        <para> Each entry is prepared with the Java Core MessageFormat methods.
+                            Therefore most functionality you can do via MessageFormat can be done
+                            here: </para>
+                        <para><tag xlink:href="http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html">Java API for MessageFormat</tag></para>
+                        <para>The caveat here is that only default String and number FormatTypes can
+                            be used. This is due to the processing described in 3 below. If support
+                            for date, time or choice is required then the GenerateLogMessages class
+                            should be updated to provide support.</para>
+                    </listitem>
+                    <listitem>
+                        <para>GenerateLogMessage/Velocity Macro</para>
+                        <para>This is the only processing that this file goes through</para>
+                        <orderedlist>
+                            <listitem>
+                                <para>Class Generation:</para>
+                                <para>The GenerateLogMessage processes this file and uses the
+                                    velocity Macro to create classes with static methods to perform
+                                    the logging and give us compile time validation. </para>
+                            </listitem>
+                            <listitem>
+                                <para>Property Processing</para>
+                                <para>During the class generation the message properties ({x}) are
+                                    identified and used to create the method signature.</para>
+                            </listitem>
+                            <listitem>
+                                <para>Option Processing</para>
+                                <para>The Classes perform final formatting of the messages at
+                                    runtime based on optional parameters that are defined within the
+                                    message. Optional parameters are enclosed in square brackets
+                                    e.g. [optional].</para>
+                            </listitem>
+                        </orderedlist>
+                    </listitem>
+                </orderedlist>
+            </para>
+            <para><emphasis role="bold">Format Note:</emphasis></para>
+            <para> As mentioned earlier white space in this file is very important. One thing in
+                particular to note is the way MessageFormat performs its replacements. The
+                replacement text will totally replace the {xxx} section so there will be no addition
+                of white space or removal e.g. </para>
+            <programlisting><![CDATA[MSG = Text----{0}----]]>
+            </programlisting>            
+            <para> When given parameter 'Hello' result in text: </para>
+            <programlisting><![CDATA[Text----Hello----]]>
+            </programlisting>
+            <para>For simple arguments this is expected however when using Style formats then it can
+                be a little unexpected. In particular a common pattern is used for number
+                replacements : {0,number,}. This is used in the Broker to display an Integer simply
+                as the Integer with no formatting. e.g new Integer(1234567) becomes the String
+                "1234567" which is can be contrasted with the pattern without a style format field :
+                {0,number} which becomes string "1,234,567".</para>
+            <para>What you may not expect is that {0,number, } would produce the String " 1234567"
+                note that the space after the ',' here has resulted in a space in front of the
+                number in the output.</para>
+            <para>More details on the SubformatPattern can be found on the API link above. To
+                provide fixed log messages as required by the Technical Specification:</para>
+            <para><tag xlink:href="http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+SpecificationOperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages">Operational Logging Tech Specification</tag></para>
+            <para>This file is processed by Velocity to create a number of classes that contain
+                static methods that provide LogMessages in the code to provide compile time
+                validation.</para>
+            <para>For details of what processing is done see GenerateLogMessages. </para>
+            <para>What a localiser or developer need know is the following: </para>
+            <para>The Property structure is important as it defines how the class and methods will
+                be built.</para>
+        </sect1>
+        <sect1>
+            <title>Class Generation</title>
+            <para> Each class of messages will be split in to their own &lt;Class>Messages.java.
+                Each logmessage file contains only one class of messages the &lt;Class> name is
+                derived from the name of the logmessages file e.g. &lt;Class&gt;_logmessages.properties.                  
+            </para>                
+        </sect1>
+        <sect1>
+            <title>Property Format</title>
+            <para>The property format MUST adhere to the follow format to make it easier to use the
+                logging API as a developer but also so that operations staff can easily locate log
+                messages in the output.</para>
+            <para>The property file should contain entries in the following format:</para>
+            <programlisting><![CDATA[<Log Identifier,developer focused>=<Log Identifier,Operate focus>:<Log Message>]]>
+            </programlisting>
+             
+            <para>eg:</para>
+            <programlisting><![CDATA[SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,}]]>
+            </programlisting>   
+            
+            <para>Note: the developer focused identifier will become a method name so only a valid
+                method name should be used. Currently only '-' are converted to '_'.</para>
+            <para>That said properties generate the logging code at build time so any error can be
+                easily identified.</para>
+            <para>The three character identifier show above in BRK-1003 should ideally be unique.
+                This is the only requirement, limiting to 3 characters is not required.</para>
+            <para>The current broker contains the following mappings:</para>
+            <para>
+                <table>
+                    <title>Status Messages Mapping</title>
+                    <tgroup cols="2">
+                        <colspec colname="c1" colnum="1" colwidth="118.29pt"/>
+                        <colspec colname="c2" colnum="2" colwidth="135.18pt"/>
+                        <thead>
+                            <row>
+                                <entry>Class</entry>
+                                <entry> Type</entry>
+                            </row>
+                        </thead>
+                        <tbody>
+                            <row>
+                                <entry>Broker</entry>
+                                <entry>BRK</entry>
+                            </row>
+                            <row>
+                                <entry>Management Console</entry>
+                                <entry>MNG</entry>
+                            </row>
+                            <row>
+                                <entry>VirtualHost</entry>
+                                <entry>VHT</entry>
+                            </row>
+                            <row>
+                                <entry>MessageStore</entry>
+                                <entry>MST</entry>
+                            </row>
+                            <row>
+                                <entry>ConfigStore</entry>
+                                <entry>CFG</entry>
+                            </row>
+                            <row>
+                                <entry>TransactionLog</entry>
+                                <entry>TXN</entry>
+                            </row>
+                            <row>
+                                <entry>Connection</entry>
+                                <entry>CON</entry>
+                            </row>
+                            <row>
+                                <entry>Channel</entry>
+                                <entry>CHN</entry>
+                            </row>
+                            <row>
+                                <entry>Queue</entry>
+                                <entry>QUE</entry>
+                            </row>
+                            <row>
+                                <entry>Exchange</entry>
+                                <entry>EXH</entry>
+                            </row>
+                            <row>
+                                <entry>Binding</entry>
+                                <entry>BND</entry>
+                            </row>
+                            <row>
+                                <entry>Subscription</entry>
+                                <entry>SUB</entry>
+                            </row>
+                        </tbody>
+                    </tgroup>
+                </table>
+            </para>
+        </sect1>
+        <sect1>
+            <title>Property Processing</title>
+                <para>
+                    Each property is then processed by the GenerateLogMessages class to identify
+                    the number and type of parameters, {x} entries. Parameters are defaulted to
+                    String types but the use of FormatType number (e.g.{0,number}) will result
+                    in a Number type being used. These parameters are then used to build the
+                    method parameter list. e.g:
+               </para>     
+            
+            <para>Property:</para>
+            <programlisting><![CDATA[SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,}]]></programlisting>                      
+            <para>becomes Method:</para>
+            <programlisting><![CDATA[public static LogMessage SHUTTING_DOWN(String param1, Number param2)]]>
+            </programlisting>
+           
+            <para>
+                This improves our compile time validation of log message content and
+            ensures that change in the message format does not accidentally cause
+            erroneous messages.</para>
+        </sect1>
+        <sect1>
+            <title>Option Processing</title>
+            <para>
+                Options are identified in the log message as being surrounded by square
+                brackets ([ ]). These optional values can themselves contain parameters
+                however nesting of options is not permitted. Identification is performed on
+                first matching so given the message:
+            </para>
+            <programlisting><![CDATA[Msg = Log Message [option1] [option2] ]]></programlisting>                        
+            <para>
+                Two options will be identified and enabled to select text 'option1' and
+                'option2'.
+            </para>
+            <para>            
+                The nesting of a options is not supported and will provide
+                unexpected results. e.g. Using Message:
+            </para>    
+            <programlisting><![CDATA[Msg = Log Message [option1 [sub-option2]] ]]></programlisting>                
+            <para>    
+                The options will be 'option1 [sub-option2' and 'sub-option2'. The first
+                option includes the second option as the nesting is not detected.
+            </para>
+            <para>            
+                The detected options are presented in the method signature as boolean options
+                numerically identified by their position in the message. e.g.
+                Property:
+            </para>                
+            <programlisting><![CDATA[ CON-1001 = Open : Client ID {0} [: Protocol Version : {1}] ]]></programlisting>                
+            <para>becomes Method:</para>            
+            <programlisting><![CDATA[ public static LogMessage CON_1001(String param1, String param2, boolean opt1) ]]></programlisting>                
+            <para>            
+                The value of 'opt1' will show/hide the option in the message. Note that
+                'param2' is still required however a null value can be used if the optional
+                section is not desired.
+            </para>
+            <para>            
+                Again here the importance of white space needs to be highlighted.
+                Looking at the QUE-1001 message as an example. The first thought on how this
+                would look would be as follows:
+            </para>
+            <programlisting><![CDATA[ QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,}] ]]></programlisting>            
+            <para>            
+                Each option is correctly defined so the text that is defined will appear when
+                selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
+                the white space. Using the above definition of QUE-1001 if we were to print
+                the message with only the Priority option displayed it would appear as this:
+            </para>
+            <programlisting><![CDATA[ "Create : Owner: guest    Priority: 1" ]]></programlisting>
+            <para>
+                Note the spaces here in between gues and Priority are present because only the text between the brackets
+                has been removed.
+            </para>
+            <para>            
+                Each option needs to include white space to correctly format the message. So
+                the correct definition of QUE-1001 is as follows:
+            </para>
+            <programlisting><![CDATA[ QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,}] ]]></programlisting> 
+            <para>            
+                Note that white space is included with each option and there is no extra
+                white space between the options. As a result the output with just Priority
+                enabled is as follows:
+            </para>
+            <programlisting><![CDATA[ "Create : Owner: guest Priority: 1" ]]></programlisting>             
+        </sect1>
+    </chapter>    
+</book>
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Binding_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Binding_logmessages.properties
index 6956a396b0..808ec7918f 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Binding_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Binding_logmessages.properties
@@ -18,196 +18,5 @@
 #
 # Default File used for all non-defined locales.
 #
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
-
 CREATED = BND-1001 : Create[ : Arguments : {0}]
 DELETED = BND-1002 : Deleted
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Broker_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Broker_logmessages.properties
index 9a0bdec929..3782026bad 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Broker_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Broker_logmessages.properties
@@ -17,197 +17,6 @@
 #  under the License.
 #
 # Default File used for all non-defined locales.
-#
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
 
 # 0 - Version
 # 1 = Build
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Channel_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Channel_logmessages.properties
index 53b8e995f4..53bcd712f2 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Channel_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Channel_logmessages.properties
@@ -17,197 +17,6 @@
 #  under the License.
 #
 # Default File used for all non-defined locales.
-#
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
 
 CREATE = CHN-1001 : Create
 # 0 - flow
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ConfigStore_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ConfigStore_logmessages.properties
index a6a36b15fe..3bc5074777 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ConfigStore_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ConfigStore_logmessages.properties
@@ -17,197 +17,6 @@
 #  under the License.
 #
 # Default File used for all non-defined locales.
-#
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
 
 # 0 - name
 CREATED = CFG-1001 : Created : {0}
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Connection_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Connection_logmessages.properties
index 08393f5e00..81ae6f3bd0 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Connection_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Connection_logmessages.properties
@@ -17,197 +17,6 @@
 #  under the License.
 #
 # Default File used for all non-defined locales.
-#
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
 
 # 0 - Client id
 # 1 - Protocol Version
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Exchange_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Exchange_logmessages.properties
index 6df7c5862c..b9890d9f27 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Exchange_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Exchange_logmessages.properties
@@ -17,197 +17,6 @@
 #  under the License.
 #
 # Default File used for all non-defined locales.
-#
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
 
 # 0 - type
 # 1 - name
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ManagementConsole_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ManagementConsole_logmessages.properties
index 910706a250..bd42425033 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ManagementConsole_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ManagementConsole_logmessages.properties
@@ -18,197 +18,6 @@
 #
 # Default File used for all non-defined locales.
 #
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
-
 STARTUP = MNG-1001 : Startup
 # 0 - Service
 # 1 - Port
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/MessageStore_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/MessageStore_logmessages.properties
index d60fafd196..a2cedeb22a 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/MessageStore_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/MessageStore_logmessages.properties
@@ -18,197 +18,6 @@
 #
 # Default File used for all non-defined locales.
 #
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
-
 # 0 - name
 CREATED = MST-1001 : Created : {0}
 # 0 - path
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Queue_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Queue_logmessages.properties
index 59a8c87f76..538bf994ea 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Queue_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Queue_logmessages.properties
@@ -18,197 +18,6 @@
 #
 # Default File used for all non-defined locales.
 #
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
-
 # 0 - owner
 # 1 - priority
 CREATED = QUE-1001 : Create :[ Owner: {0}][ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Subscription_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Subscription_logmessages.properties
index 7ad62d2049..ef5f885b50 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Subscription_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Subscription_logmessages.properties
@@ -18,197 +18,6 @@
 #
 # Default File used for all non-defined locales.
 #
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
-
 CREATE = SUB-1001 : Create[ : Durable][ : Arguments : {0}]
 CLOSE = SUB-1002 : Close
 # 0 - The current subscription state
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/TransactionLog_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/TransactionLog_logmessages.properties
index fe50134cdd..fadc2e2098 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/TransactionLog_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/TransactionLog_logmessages.properties
@@ -18,197 +18,7 @@
 #
 # Default File used for all non-defined locales.
 #
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
 #
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
-
 # 0 - name
 CREATED = TXN-1001 : Created : {0}
 # 0 - path
diff --git a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/VirtualHost_logmessages.properties b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/VirtualHost_logmessages.properties
index 3129844495..66bbefacb0 100644
--- a/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/VirtualHost_logmessages.properties
+++ b/qpid/java/broker/src/main/java/org/apache/qpid/server/logging/messages/VirtualHost_logmessages.properties
@@ -18,197 +18,6 @@
 #
 # Default File used for all non-defined locales.
 #
-# This file was derivied from LogMessages used within the Java Broker and
-# originally defined on the wiki:
-# http://cwiki.apache.org/confluence/display/qpid/Status+Update+Design#StatusUpdateDesign-InitialStatusMessages
-#
-# Technical Notes:
-#  This is a standard Java Properties file so white space is respected at the
-#  end of the lines. This file is processed in a number of ways.
-# 1) ResourceBundle
-#   This file is loaded as a ResourceBundle. The en_US
-#   addition to the file is the localisation. Additional localisations can be
-#   provided and will automatically be selected based on the <locale> value in
-#   the config.xml. The default is en_US.
-#
-# 2) MessasgeFormat
-#  Each entry is prepared with the Java Core MessageFormat methods. Therefore
-#  most functionality you can do via MessageFormat can be done here:
-#
-#  http://java.sun.com/javase/6/docs/api/java/text/MessageFormat.html
-#
-#  The cavet here is that only default String and number FormatTypes can be used.
-#  This is due to the processing described in 3 below. If support for date, time
-#  or choice is required then the GenerateLogMessages class should be updated to
-#  provide support.
-#
-#  Format Note:
-#   As mentioned earlier white space in this file is very important. One thing
-#  in particular to note is the way MessageFormat performs its replacements.
-#  The replacement text will totally replace the {xxx} section so there will be
-#  no addition of white space or removal e.g.
-#     MSG = Text----{0}----
-#  When given parameter 'Hello' result in text:
-#     Text----Hello----
-#
-#  For simple arguments this is expected however when using Style formats then
-#  it can be a little unexpected. In particular a common pattern is used for
-#  number replacements : {0,number,#}. This is used in the Broker to display an
-#  Integer simply as the Integer with no formatting. e.g new Integer(1234567)
-#  becomes the String "1234567" which is can be contrasted with the pattern
-#  without a style format field : {0,number} which becomes string "1,234,567".
-#
-#  What you may not expect is that {0,number, #} would produce the String " 1234567"
-#  note the space after the ','   here      /\   has resulted in a space  /\ in
-#  the output.
-#
-#  More details on the SubformatPattern can be found on the API link above.
-#
-# 3) GenerateLogMessage/Velocity Macro
-#  This is the only processing that this file goes through.
-#   1) Class Generation:
-#      The GenerateLogMessage processes this file and uses the velocity Macro
-#      to create classes with static methods to perform the logging and give us
-#      compile time validation.
-#
-#   2) Property Processing:
-#      During the class generation the message properties ({x}) are identified
-#      and used to create the method signature.
-#
-#   3) Option Processing:
-#      The Classes perform final formatting of the messages at runtime based on
-#      optional parameters that are defined within the message. Optional
-#      parameters are enclosed in square brackets e.g. [optional].
-#
-#  To provide fixed log messages as required by the Technical Specification:
-#  http://cwiki.apache.org/confluence/display/qpid/Operational+Logging+-+Status+Update+-+Technical+Specification#OperationalLogging-StatusUpdate-TechnicalSpecification-Howtoprovidefixedlogmessages
-#
-#  This file is processed by Velocity to create a number of classes that contain
-#  static methods that provide LogMessages in the code to provide compile time
-#  validation.
-#
-#  For details of what processing is done see GenerateLogMessages.
-#
-#  What a localiser or developer need know is the following:
-#
-#  The Property structure is important as it defines how the class and methods
-#  will be built.
-#
-#  Class Generation:
-#  =================
-#
-#  Each class of messages will be split in to their own <Class>Messages.java.
-#  Each logmessage file contains only one class of messages the <Class> name
-#  is derived from the name of the logmessages file e.g. <Class>_logmessages.properties.
-#
-#  Property Format
-#  ===============
-#   The property format MUST adhere to the follow format to make it easier to
-#   use the logging API as a developer but also so that operations staff can
-#   easily locate log messages in the output.
-#
-#   The property file should contain entries in the following format
-#
-#   <Log Identifier, developer focused> = <Log Identifier, Operate focus> : <Log Message>
-#
-#   eg:
-#    SHUTTING_DOWN = BRK-1003 : Shutting down : {0} port {1,number,#}
-#
-#   Note: the developer focused identifier will become a method name so only a
-#   valid method name should be used. Currently only '-' are converted to '_'.
-#
-#   That said properties generate the logging code at build time so any error
-#   can be easily identified.
-#
-#  The three character identifier show above in BRK-1003 should ideally be unique.
-#  This is the only requirement, limiting to 3 characters is not required.
-#  That said the current broker contains the following mappings.
-#
-#        Class              | Type
-#      ---------------------|--------
-#        Broker             |  BKR
-#        ManagementConsole  |  MNG
-#        VirtualHost        |  VHT
-#        MessageStore       |  MST
-#        ConfigStore        |  CFG
-#        TransactionLog     |  TXN
-#        Connection         |  CON
-#        Channel            |  CHN
-#        Queue              |  QUE
-#        Exchange           |  EXH
-#        Binding            |  BND
-#        Subscription       |  SUB
-#
-#
-#  Property Processing:
-#  ====================
-#
-#   Each property is then processed by the GenerateLogMessages class to identify
-#   The number and type of parameters, {x} entries. Parameters are defaulted to
-#   String types but the use of FormatType number (e.g.{0,number}) will result
-#   in a Number type being used. These parameters are then used to build the
-#   method parameter list. e.g:
-#   Property:
-#    SHUTTING_DOWN = BRK-1003 : Shuting down : {0} port {1,number,#}
-#   becomes Method:
-#    public static LogMessage SHUTTING_DOWN(String param1, Number param2)
-#
-#   This improves our compile time validation of log message content and
-#   ensures that change in the message format does not accidentally cause
-#   erroneous messages.
-#
-#  Option Processing:
-#  ====================
-#
-#  Options are identified in the log message as being surrounded by square
-#  brackets ([ ]). These optional values can themselves contain parameters
-#  however nesting of options is not permitted. Identification is performed on
-#  first matching so given the message:
-#   Msg = Log Message [option1] [option2]
-#  Two options will be identified and enabled to select text 'option1' and
-#  'option2'.
-#
-#  The nesting of a options is not supported and will provide
-#  unexpected results. e.g. Using Message:
-#   Msg = Log Message [option1 [sub-option2]]
-#
-#  The options will be 'option1 [sub-option2' and 'sub-option2'. The first
-#  option includes the second option as the nesting is not detected.
-#
-#  The detected options are presented in the method signature as boolean options
-#  numerically identified by their position in the message. e.g.
-#   Property:
-#    CON-1001 = Open : Client ID {0} [: Protocol Version : {1}]
-#  becomes Method:
-#    public static LogMessage CON_1001(String param1, String param2, boolean opt1)
-#
-#  The value of 'opt1' will show/hide the option in the message. Note that
-#  'param2' is still required however a null value can be used if the optional
-#  section is not desired.
-#
-#  Again here the importance of white space needs to be highlighted.
-#  Looking at the QUE-1001 message as an example. The first thought on how this
-#  would look would be as follows:
-# QUE-1001 = Create : Owner: {0} [AutoDelete] [Durable] [Transient] [Priority: {1,number,#}]
-#  Each option is correctly defined so the text that is defined will appear when
-#  selected. e.g. 'AutoDelete'. However, what may not be immediately apparent is
-#  the white space. Using the above definition of QUE-1001 if we were to print
-#  the message with only the Priority option displayed it would appear as this:
-#  "Create : Owner: guest    Priority: 1"
-#  Note the spaces here   /\ This is because only the text between the brackets
-#  has been removed.
-#
-#  Each option needs to include white space to correctly format the message. So
-#  the correct definition of QUE-1001 is as follows:
-# QUE-1001 = Create : Owner: {0}[ AutoDelete][ Durable][ Transient][ Priority: {1,number,#}]
-#  Note that white space is included with each option and there is no extra
-#  white space between the options. As a result the output with just Priority
-#  enabled is as follows:
-#  "Create : Owner: guest Priority: 1"
-#
-#
-# Default File used for all non-defined locales.
-
 # 0 - name
 CREATED = VHT-1001 : Created : {0}
 CLOSED = VHT-1002 : Closed
\ No newline at end of file