Both Module and ClassName fields in new Custom Handler dialog are disabled. Steps to Reproduce: 1. Navigate to Profile - Core - Logging 2. Click custom tab 3. Click add button 4. See the issue with these fields.
This affects customer as consequently it is not possible to add Custom Login Handler through console.
James Perkins <jperkins> made a comment on jira WFLY-2183 [~heiko.braun] these aren't and shouldn't be writable attributes. They are used on the {{add}} operation only.
Brian Stansberry <brian.stansberry> made a comment on jira WFLY-2183 James, what does the :read-operation-description for the :add op look like? Are these parameters present?
James Perkins <jperkins> made a comment on jira WFLY-2183 Indeed they are and noted as required. _Note: Omitted the filter value-type_ {code} { "outcome" => "success", "result" => { "operation-name" => "add", "description" => "Add a new logging handler.", "request-properties" => { "enabled" => { "type" => BOOLEAN, "description" => "If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages.", "expressions-allowed" => true, "required" => false, "nillable" => true, "default" => true }, "module" => { "type" => STRING, "description" => "The module that the logging handler depends on.", "expressions-allowed" => false, "required" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L }, "class" => { "type" => STRING, "description" => "The logging handler class to be used.", "expressions-allowed" => false, "required" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L }, "named-formatter" => { "type" => STRING, "description" => "The name of the defined formatter to be used on the handler.", "expressions-allowed" => false, "required" => false, "nillable" => true, "alternatives" => ["formatter"], "min-length" => 1L, "max-length" => 2147483647L }, "properties" => { "type" => OBJECT, "description" => "Defines the properties used for the logging handler. All properties must be accessible via a setter method.", "expressions-allowed" => true, "required" => false, "nillable" => true, "value-type" => STRING }, "formatter" => { "type" => STRING, "description" => "Defines a pattern for the formatter.", "expressions-allowed" => true, "required" => false, "nillable" => true, "default" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n", "alternatives" => ["named-formatter"], "min-length" => 1L, "max-length" => 2147483647L }, "filter-spec" => { "type" => STRING, "description" => "A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match(\"JBAS.*\"))", "expressions-allowed" => true, "required" => false, "nillable" => true, "alternatives" => ["filter"], "min-length" => 1L, "max-length" => 2147483647L }, "level" => { "type" => STRING, "description" => "The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded.", "expressions-allowed" => true, "required" => false, "nillable" => true, "default" => "ALL", "allowed" => [ "ALL", "FINEST", "FINER", "TRACE", "DEBUG", "FINE", "CONFIG", "INFO", "WARN", "WARNING", "ERROR", "FATAL", "OFF" ] }, "name" => { "type" => STRING, "description" => "The handler's name.", "expressions-allowed" => false, "required" => false, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L, "deprecated" => { "since" => "1.2.0", "reason" => "The name attribute should not be used as the handler's address contains the name." } }, "encoding" => { "type" => STRING, "description" => "The character encoding used by this Handler.", "expressions-allowed" => true, "required" => false, "nillable" => true, "min-length" => 1L, "max-length" => 2147483647L }, "filter" => { "type" => OBJECT, "description" => "Defines a simple filter type.", "expressions-allowed" => false, "required" => false, "nillable" => true, "alternatives" => ["filter-spec"], "deprecated" => { "since" => "1.2.0", "reason" => "Use filter-spec." }, "value-type" => { } }, "reply-properties" => {}, "read-only" => false } } {code}
Brian Stansberry <brian.stansberry> made a comment on jira WFLY-2183 Thanks, James. That's the expected metadata then for an attribute that cannot be modified after creation.
James Perkins <jperkins> made a comment on jira WFLY-2183 [~heiko.braun] This is not an issue with the logging subsystem. While the attributes are not writable and should be locked during an update, they are required by the add operation. I'm attaching the screen shot of an add operation. AFAIK there is no requirement that all attributes be writable.
Fixed in HAL 2.0.5.Final
Verified 6.2.0.ER7