[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2252:
-------------------------------------
Description:
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
AttributeDefinition should reject the combination of a default value and required=true in its constructor.
I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
was:
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
AttributeDefinition should reject this combination in its constructor.
I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-2252
> URL: https://issues.jboss.org/browse/WFCORE-2252
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject the combination of a default value and required=true in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2252:
-------------------------------------
Fix Version/s: 4.0.0.Beta1
Moving to consideration in WildFly Core 4. Too disruptive at this stage for 3.
> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-2252
> URL: https://issues.jboss.org/browse/WFCORE-2252
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject this combination in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-1539) NAKACK2: xmit_interval sometimes triggers unneeded retransmissions
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1539?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1539:
---------------------------
Description:
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message.
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
- At time T1009, messages 6-19 are received
Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Had the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.
The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
Another reason is also that the message bundler on the sender side might send messages in random order (see link below).
SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.
was:
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message.
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
- At time T1009, messages 6-19 are received
Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Has the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.
The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
Another reason is also that the message bundler on the sender side might send messages in random order (see link below).
SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.
> NAKACK2: xmit_interval sometimes triggers unneeded retransmissions
> ------------------------------------------------------------------
>
> Key: JGRP-1539
> URL: https://issues.jboss.org/browse/JGRP-1539
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message.
> Example:
> - Messages 1,2,3,4,5 are received at time T0 (in ms)
> - At time T1000, message 20 is received
> - At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
> - At time T1009, messages 6-19 are received
> Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Had the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.
> The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
> Another reason is also that the message bundler on the sender side might send messages in random order (see link below).
> SOLUTION:
> Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-903) Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-903:
-----------------------------
Attachment: print-roles.war
> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
> Key: ELY-903
> URL: https://issues.jboss.org/browse/ELY-903
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta21
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Attachments: print-roles.war
>
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-903) Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-903:
-----------------------------
Component/s: Realms
> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
> Key: ELY-903
> URL: https://issues.jboss.org/browse/ELY-903
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta21
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-903) Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-903:
--------------------------------
Summary: Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
Key: ELY-903
URL: https://issues.jboss.org/browse/ELY-903
Project: WildFly Elytron
Issue Type: Bug
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
Most important part of ldif for reproduction is following:
{code}
dn: cn=R1,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R1
member: uid=jduke,ou=People,dc=jboss,dc=org
description: the R1 group
dn: cn=R2,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R2
member: uid=jduke,ou=People,dc=jboss,dc=org
member: cn=R1,ou=Roles,dc=jboss,dc=org
description: the R2 group
dn: cn=R3,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R3
member: cn=R2,ou=Roles,dc=jboss,dc=org
description: the R3 group
{code}
User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-903) Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-903:
-----------------------------
Affects Version/s: 1.1.0.Beta21
> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
> Key: ELY-903
> URL: https://issues.jboss.org/browse/ELY-903
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta21
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8007) Replace WorkManager elytron-enabled atttribute by elytron-security-domain
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-8007:
------------------------------------
Summary: Replace WorkManager elytron-enabled atttribute by elytron-security-domain
Key: WFLY-8007
URL: https://issues.jboss.org/browse/WFLY-8007
Project: WildFly
Issue Type: Enhancement
Components: JCA
Reporter: Flavia Rainone
Assignee: Stefano Maestri
Right now the elytron-enabled attribute does not allow the dependency on the security domain capability. We need to replace it by elytron-security-domain and have the capability dependency sorted out.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2254) InterdependentDeploymentTestCase fails with security manager
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2254?page=com.atlassian.jira.plugi... ]
Jan Tymel reassigned WFCORE-2254:
---------------------------------
Assignee: (was: Tomaz Cerar)
> InterdependentDeploymentTestCase fails with security manager
> ------------------------------------------------------------
>
> Key: WFCORE-2254
> URL: https://issues.jboss.org/browse/WFCORE-2254
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
>
> *org.jboss.as.test.manualmode.deployment.InterdependentDeploymentTestCase#test*
> {{cd testsuite/manualmode/}}
> {{mvn test -DtestLogToFile=false -Dtest=InterdependentDeploymentTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service ServiceActivatorDeployment.c: org.jboss.msc.service.StartException in service ServiceActivatorDeployment.c: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "interrelated-c.jar" "write")" in code source "(vfs:/content/interrelated-a.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.interrelated-a.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.System.setProperty(System.java:792)
> at org.jboss.as.test.deployment.trivial.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 4 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2254) InterdependentDeploymentTestCase fails with security manager
by Jan Tymel (JIRA)
Jan Tymel created WFCORE-2254:
---------------------------------
Summary: InterdependentDeploymentTestCase fails with security manager
Key: WFCORE-2254
URL: https://issues.jboss.org/browse/WFCORE-2254
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Reporter: Jan Tymel
Assignee: Tomaz Cerar
*org.jboss.as.test.manualmode.deployment.InterdependentDeploymentTestCase#test*
{{cd testsuite/manualmode/}}
{{mvn test -DtestLogToFile=false -Dtest=InterdependentDeploymentTestCase -Dsecurity.manager}}
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service ServiceActivatorDeployment.c: org.jboss.msc.service.StartException in service ServiceActivatorDeployment.c: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "interrelated-c.jar" "write")" in code source "(vfs:/content/interrelated-a.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.interrelated-a.jar" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.System.setProperty(System.java:792)
at org.jboss.as.test.deployment.trivial.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:91)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
... 4 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months