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/qpid@990146 13f79535-47bb-0310-9956-ffa450edef68

12 files changed, 0 insertions, 2291 deletions

diff --git a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Binding_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Binding_logmessages.properties
index 6956a396b0..808ec7918f 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Binding_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Broker_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Broker_logmessages.properties
index 9a0bdec929..3782026bad 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Broker_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Channel_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Channel_logmessages.properties
index 53b8e995f4..53bcd712f2 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Channel_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ConfigStore_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ConfigStore_logmessages.properties
index a6a36b15fe..3bc5074777 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ConfigStore_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Connection_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Connection_logmessages.properties
index 08393f5e00..81ae6f3bd0 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Connection_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Exchange_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Exchange_logmessages.properties
index 6df7c5862c..b9890d9f27 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Exchange_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ManagementConsole_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ManagementConsole_logmessages.properties
index 910706a250..bd42425033 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/ManagementConsole_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/MessageStore_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/MessageStore_logmessages.properties
index d60fafd196..a2cedeb22a 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/MessageStore_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Queue_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Queue_logmessages.properties
index 59a8c87f76..538bf994ea 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Queue_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Subscription_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Subscription_logmessages.properties
index 7ad62d2049..ef5f885b50 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/Subscription_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/TransactionLog_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/TransactionLog_logmessages.properties
index fe50134cdd..fadc2e2098 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/TransactionLog_logmessages.properties
+++ b/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/java/broker/src/main/java/org/apache/qpid/server/logging/messages/VirtualHost_logmessages.properties b/java/broker/src/main/java/org/apache/qpid/server/logging/messages/VirtualHost_logmessages.properties
index 3129844495..66bbefacb0 100644
--- a/java/broker/src/main/java/org/apache/qpid/server/logging/messages/VirtualHost_logmessages.properties
+++ b/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