Bug 1013521
Summary: | Module and ClassName fields are disabled in new Custom handler dialog | ||
---|---|---|---|
Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Jakub Cechacek <jcechace> |
Component: | Web Console | Assignee: | Heiko Braun <hbraun> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Jakub Cechacek <jcechace> |
Severity: | urgent | Docs Contact: | Russell Dickenson <rdickens> |
Priority: | unspecified | ||
Version: | 6.2.0 | CC: | brian.stansberry, emuckenh, hbraun, hpehl, jkudrnac |
Target Milestone: | ER7 | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-12-15 16:14:48 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jakub Cechacek
2013-09-30 09:30:53 UTC
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 |