[JBoss JIRA] (WFLY-5943) Picketlink federation and idm subsystems have no parsers for their 1.1 schemas
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5943?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-5943:
--------------------------------------
Assignee: Brian Stansberry (was: Pedro Igor)
I'll deal with this as it's more convenient to fix this at the same time as WFLY-5944. Turns out the xsds are the same except for the number.
> Picketlink federation and idm subsystems have no parsers for their 1.1 schemas
> -------------------------------------------------------------------------------
>
> Key: WFLY-5943
> URL: https://issues.jboss.org/browse/WFLY-5943
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
>
> EAP 6.4 has a 1.1 xsd version for these subsystems, while WF 10 / EAP 7 has a 2.0. A quick glance leads me to believe the contents are the same except for the number. But the WF 10 / EAP 7 code will fail if a document with the 1.1 namespace is presented.
> If the xsds are the same, likely this can be fixed simply by adding another case for 1.1 to the switch block that calls the 2.0 parser. Otherwise the 1.1 parser from the EAP 6 branch should be forward ported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5943) Picketlink federation and idm subsystems have no parsers for their 1.1 schemas
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5943?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved JBEAP-2586 to WFLY-5943:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5943 (was: JBEAP-2586)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Security
(was: Security)
Target Release: (was: 7.0.0.GA)
> Picketlink federation and idm subsystems have no parsers for their 1.1 schemas
> -------------------------------------------------------------------------------
>
> Key: WFLY-5943
> URL: https://issues.jboss.org/browse/WFLY-5943
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Brian Stansberry
> Assignee: Pedro Igor
> Priority: Critical
>
> EAP 6.4 has a 1.1 xsd version for these subsystems, while WF 10 / EAP 7 has a 2.0. A quick glance leads me to believe the contents are the same except for the number. But the WF 10 / EAP 7 code will fail if a document with the 1.1 namespace is presented.
> If the xsds are the same, likely this can be fixed simply by adding another case for 1.1 to the switch block that calls the 2.0 parser. Otherwise the 1.1 parser from the EAP 6 branch should be forward ported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5890) Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5890?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5890:
---------------------------------
Priority: Critical (was: Major)
> Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5890
> URL: https://issues.jboss.org/browse/WFLY-5890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Labels: ux
>
> h3. Problem
> Wildfly 10's default load metric changed from *busyness* to *cpu*. Although otherwise fine, this change has a one major drawback: It doesn't work on Windows JDKs: MODCLUSTER-234. This fact has been known and acknowledged since 2011.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Instead of a valid Load value, subsystem returns 0 and prints: {{MODCLUSTER000045: AverageSystemLoadMetric is not supported on this system and will be disabled.}}
> h3. Example
> {code}
> C:\Users\Administrator>groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: -1.0
> avail. processors: 4
> {code}
> {code}
> mbabacek@localhost:~$ groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: 0.67
> avail. processors: 4
> {code}
> h3. Call to action
> IMHO, this is a Major user experience failure, the default should provide meaningful values on all major platforms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1273) Can not add property after change of class in custom log formatter.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1273?page=com.atlassian.jira.plugi... ]
James Perkins moved JBEAP-2581 to WFCORE-1273:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1273 (was: JBEAP-2581)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Logging
(was: Logging)
Target Release: (was: 7.0.0.GA)
> Can not add property after change of class in custom log formatter.
> -------------------------------------------------------------------
>
> Key: WFCORE-1273
> URL: https://issues.jboss.org/browse/WFCORE-1273
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Environment: Running unsecured EAP 7.0. DR9 version in standalone mode with standalone-full-ha profile
> Reporter: James Perkins
> Assignee: James Perkins
>
> When you create custom formater - XMLFormatter {{/subsystem=logging/custom-formatter=XMLFormatter:add(class=java.util.logging.XMLFormatter, module=org.jboss.logmanager)}} and then in web console edit class of formatter to *org.jboss.logmanager.formatters.PatternFormatter* then save and try to add properties - *pattern=%s%E%n*. Property is not saved.
> When you create new formatter with *org.jboss.logmanager.formatters.PatternFormatter* class and then try to add same property, saving is successful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months