[JBoss JIRA] (WFLY-1023) Add Missing Error Counts for Servlets
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1023?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-1023:
---------------------------------
Assignee: Stuart Douglas (was: Remy Maucherat)
> Add Missing Error Counts for Servlets
> -------------------------------------
>
> Key: WFLY-1023
> URL: https://issues.jboss.org/browse/WFLY-1023
> Project: WildFly
> Issue Type: Enhancement
> Components: Web (Undertow)
> Environment: All applicable environments.
> Reporter: Fernando Ribeiro
> Assignee: Stuart Douglas
>
> Unlike in previous versions of AS, there aren't error counts for each servlet, but only a total in the connector.
> These useful counts were used by many monitoring tools (e.g: RHQ/JON and dynaTrace), and should be available in AS 7 too.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-3340) Authentication "module-options" inconsistently hash vs list of key/values
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3340?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3340:
-----------------------------------
I think this was resolved around 7.2.0 times when whole security subsystem moved to resources instead of complex attributes.
> Authentication "module-options" inconsistently hash vs list of key/values
> -------------------------------------------------------------------------
>
> Key: WFLY-3340
> URL: https://issues.jboss.org/browse/WFLY-3340
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: RHEL 6.4, x86_64
> Reporter: Chris Pitman
> Assignee: Brian Stansberry
> Labels: automation, cli, configuration_management
>
> When adding an authentication mechanism to a security domain it is possible to set the module-options with a hash (which is great!). However, as soon as a reload occurs they revert back into a list of key-value pairs. This only makes sense if order matters (which I hope it doesn't) or if keys can be repeated (again, hope not).
> Configuration management tools should only change a value when it needs to, and this is way easier if the value that is set is the same value that is read. Hashes are also far easier to work with in ruby/puppet/chef.
> Steps to reproduce:
> 1. Set the module_options on an already existing authentication mechanism:
> {code}
> /subsystem=security/security-domain=servlet-security-quickstart/authentication=classic:write-attribute(name=login-modules, value=[{"code" => "Database","flag"=>"required","module-options"=>{"dsJndiName" =>
> "java:jboss/datasources/ServletSecurityDS", "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?", "role
> sQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"}}])
> {code}
> 2. Read the resource (notice that module-options is till a nice easy to use hash!)
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "module-options" => {
> "dsJndiName" => "java:jboss/datasources/ServletSecurityDS",
> "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?",
> "rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"
> },
> "flag" => "required",
> "code" => "Database"
> }]},
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> 3. Reload, then read-resource
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "code" => "Database",
> "flag" => "required",
> "module-options" => [
> ("dsJndiName" => "java:jboss/datasources/ServletSecurityDS"),
> ("principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?"),
> ("rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?")
> ]
> }]}
> }
> {code}
> 4. module-options is now a list of key-value pairs, and is not equal to what it was set to before
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-3564) Remove support for mixed-domain transforming to < 7.3.0 versions
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3564?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3564:
------------------------------
Summary: Remove support for mixed-domain transforming to < 7.3.0 versions (was: Remove support for mixed-domain transforming to 7.1.x versions)
> Remove support for mixed-domain transforming to < 7.3.0 versions
> ----------------------------------------------------------------
>
> Key: WFLY-3564
> URL: https://issues.jboss.org/browse/WFLY-3564
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> (Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.)
> We will not support WF 9 mixed domains with slaves running releases prior to 7.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running.
> KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-3564) Remove support for mixed-domain transforming to < 7.3.0 versions
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3564?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3564:
------------------------------
Description:
(Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.)
We will not support WF 9 mixed domains with slaves running releases prior to 7.3 / EAP 6.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running.
KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource.
was:
(Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.)
We will not support WF 9 mixed domains with slaves running releases prior to 7.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running.
KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource.
> Remove support for mixed-domain transforming to < 7.3.0 versions
> ----------------------------------------------------------------
>
> Key: WFLY-3564
> URL: https://issues.jboss.org/browse/WFLY-3564
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> (Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.)
> We will not support WF 9 mixed domains with slaves running releases prior to 7.3 / EAP 6.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running.
> KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-3340) Authentication "module-options" inconsistently hash vs list of key/values
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3340?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-3340.
------------------------------------
Assignee: Brian Stansberry (was: Alexey Loubyansky)
Resolution: Out of Date
Problem no longer exists in latest master.
> Authentication "module-options" inconsistently hash vs list of key/values
> -------------------------------------------------------------------------
>
> Key: WFLY-3340
> URL: https://issues.jboss.org/browse/WFLY-3340
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: RHEL 6.4, x86_64
> Reporter: Chris Pitman
> Assignee: Brian Stansberry
> Labels: automation, cli, configuration_management
>
> When adding an authentication mechanism to a security domain it is possible to set the module-options with a hash (which is great!). However, as soon as a reload occurs they revert back into a list of key-value pairs. This only makes sense if order matters (which I hope it doesn't) or if keys can be repeated (again, hope not).
> Configuration management tools should only change a value when it needs to, and this is way easier if the value that is set is the same value that is read. Hashes are also far easier to work with in ruby/puppet/chef.
> Steps to reproduce:
> 1. Set the module_options on an already existing authentication mechanism:
> {code}
> /subsystem=security/security-domain=servlet-security-quickstart/authentication=classic:write-attribute(name=login-modules, value=[{"code" => "Database","flag"=>"required","module-options"=>{"dsJndiName" =>
> "java:jboss/datasources/ServletSecurityDS", "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?", "role
> sQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"}}])
> {code}
> 2. Read the resource (notice that module-options is till a nice easy to use hash!)
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "module-options" => {
> "dsJndiName" => "java:jboss/datasources/ServletSecurityDS",
> "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?",
> "rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"
> },
> "flag" => "required",
> "code" => "Database"
> }]},
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> 3. Reload, then read-resource
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "code" => "Database",
> "flag" => "required",
> "module-options" => [
> ("dsJndiName" => "java:jboss/datasources/ServletSecurityDS"),
> ("principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?"),
> ("rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?")
> ]
> }]}
> }
> {code}
> 4. module-options is now a list of key-value pairs, and is not equal to what it was set to before
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-561) Disable runtime statistics by default; improve usability of enabling/disabling them
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-561?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved WFLY-561.
-----------------------------------
Assignee: Brian Stansberry
Resolution: Done
I'm not aware of any further exceptions to the standard handling of these.
> Disable runtime statistics by default; improve usability of enabling/disabling them
> -----------------------------------------------------------------------------------
>
> Key: WFLY-561
> URL: https://issues.jboss.org/browse/WFLY-561
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Beta1
>
>
> Ensure that all core resources and standard subsystem resources that gather runtime statistics have statistics gathering disabled by default. The default configuration should be optimized for performance.
> Ensure that the mechanism to enable/disable statistics gathering is consistent across resources (i.e. a boolean attribute with a consistent name and location in the relevant portion of the resource tree).
> Implement other relevant points agreed upon in the November 2012 AS design meetings in Brno.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-3564) Remove support for mixed-domain transforming to 7.1.x versions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3564?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-3564:
--------------------------------------
Assignee: Tomaz Cerar
Tomaz, I just noticed this one, and it seems you've already done most of it anyway!
> Remove support for mixed-domain transforming to 7.1.x versions
> --------------------------------------------------------------
>
> Key: WFLY-3564
> URL: https://issues.jboss.org/browse/WFLY-3564
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> (Deliberately currently unscheduled as I don't want this to become a priority unless there is clear need.)
> We will not support WF 9 mixed domains with slaves running releases prior to 7.2 (and maybe later) so we should remove the various transformer logic meant to deal with the fact that slaves in those early releases did not provide information about the version of subsystems they are running.
> KnownVersions can go, as can bits of logic that logged warns or errors instead of failing the transformation because the master could not know if the slave was going to ignore the resource.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFCORE-593) Inconsistent DMR response structure
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-593?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-593:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
Emmanuel,
When you get a chance please try a bit to see if you can learn how to reproduce this, and if you can't please resolve it as Cannot Reproduce.
> Inconsistent DMR response structure
> -----------------------------------
>
> Key: WFCORE-593
> URL: https://issues.jboss.org/browse/WFCORE-593
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: ehsavoie Hugonnet
>
> {noformat}
> {
> "address" => [
> ("profile" => "full"),
> ("subsystem" => "ejb3"),
> ("service" => "*")
> ],
> "operation" => "read-resource-description"
> }
> {
> "outcome" => "success",
> "result" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014883: No resource definition is registered for address [
> (\"profile\" => \"full\"),
> (\"subsystem\" => \"ejb3\"),
> (\"service\" => \"*\")
> ]",
> "rolled-back" => true
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFCORE-593) Inconsistent DMR response structure
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-593?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3706 to WFCORE-593:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-593 (was: WFLY-3706)
Component/s: Domain Management
(was: Domain Management)
> Inconsistent DMR response structure
> -----------------------------------
>
> Key: WFCORE-593
> URL: https://issues.jboss.org/browse/WFCORE-593
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
>
> {noformat}
> {
> "address" => [
> ("profile" => "full"),
> ("subsystem" => "ejb3"),
> ("service" => "*")
> ],
> "operation" => "read-resource-description"
> }
> {
> "outcome" => "success",
> "result" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014883: No resource definition is registered for address [
> (\"profile\" => \"full\"),
> (\"subsystem\" => \"ejb3\"),
> (\"service\" => \"*\")
> ]",
> "rolled-back" => true
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFCORE-592) Suspect handling of SaslPolicyResource attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-592?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1677 to WFCORE-592:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-592 (was: WFLY-1677)
Component/s: Domain Management
Remoting
(was: Domain Management)
(was: Remoting)
> Suspect handling of SaslPolicyResource attributes
> -------------------------------------------------
>
> Key: WFCORE-592
> URL: https://issues.jboss.org/browse/WFCORE-592
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Reporter: Brian Stansberry
>
> The SaslPolicyResource attribute all have a default value of "true" but their handling in the runtime OSH is resulting in "true" not being propagated to the remoting services if the attribute is undefined. And looking at how org.jboss.sasl works, it seems that for at least some of these the actual behavior if not set is "false". So either our metadata is wrong, or the intended value isn't getting passed to remoting. I expect its the former.
> Either way, once the metadata is correct the OSH should be passing the AD's default value into remoting, not ignoring it.
> See https://github.com/wildfly/wildfly/pull/4733/files#diff-28
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months