[JBoss JIRA] (WFLY-2270) Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738]
Verified with EAP 6.2.0.ER7.
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-2270
> URL: https://issues.jboss.org/browse/WFLY-2270
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
> <host-scoped-roles>
> <role name="master-Monitior" base-role="MONITOR">
> <host name="master"/>
> </role>
> </host-scoped-roles>
> {code}
> {code}
> <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain@localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
> "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller] ("core-service" => "management"),
> [Host Controller] ("access" => "authorization"),
> [Host Controller] ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2270) Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738] from ON_QA to VERIFIED
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-2270
> URL: https://issues.jboss.org/browse/WFLY-2270
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
> <host-scoped-roles>
> <role name="master-Monitior" base-role="MONITOR">
> <host name="master"/>
> </role>
> </host-scoped-roles>
> {code}
> {code}
> <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain@localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
> "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller] ("core-service" => "management"),
> [Host Controller] ("access" => "authorization"),
> [Host Controller] ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (JBADMCON-174) Add feature in management console to define JNDI bindings from management console
by Anurag Debnath (JIRA)
[ https://issues.jboss.org/browse/JBADMCON-174?page=com.atlassian.jira.plug... ]
Anurag Debnath deleted JBADMCON-174:
------------------------------------
> Add feature in management console to define JNDI bindings from management console
> ---------------------------------------------------------------------------------
>
> Key: JBADMCON-174
> URL: https://issues.jboss.org/browse/JBADMCON-174
> Project: JBoss Admin Console
> Issue Type: Feature Request
> Reporter: Abhijit Humbe
>
> . Proposed title of this feature request
> Grant access permission for sub packages to role 'package.admin'
> 2. Who is the customer behind the request?
> Account:Biomerieux (acct #643034)
> TAM customer: No
> SRM customer: No
> Strategic: No
> 3. What is the nature and description of the request?
> Customer want to define specific JNDI bindings from management console.
> Through the management interface, the Profile ==> Container ==> Naming does not show up.
> 4. Why does the customer need this? (List the business requirements here)
> Customer dont want to use CLI command for this,running CLI command remotely means there is a component deployed on remote machine.
> There are several dependencies on this like Java being the biggest one, network...etc
> customer want to perform all task from admin console only.
> 5. How would the customer like to achieve this? (List the functional requirements here)
> Add "Naming" field(like EJB 3, EE,..etc) under "Profile ==> Container" in management console to specify JNDI bindings.
> 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
> 7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
> 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
> TODO
> 9. Is the sales team involved in this request and do they have any additional input?
>
> 10. List any affected packages or components.
> JBoss Admin console
> 11. Would the customer be able to assist in testing this functionality if implemented?
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (JBADMCON-174) Add feature in management console to define JNDI bindings from management console
by Abhijit Humbe (JIRA)
Abhijit Humbe created JBADMCON-174:
--------------------------------------
Summary: Add feature in management console to define JNDI bindings from management console
Key: JBADMCON-174
URL: https://issues.jboss.org/browse/JBADMCON-174
Project: JBoss Admin Console
Issue Type: Feature Request
Components: General Console
Affects Versions: 1.0 alpha, 1.1 alpha
Reporter: Abhijit Humbe
. Proposed title of this feature request
Grant access permission for sub packages to role 'package.admin'
2. Who is the customer behind the request?
Account:Biomerieux (acct #643034)
TAM customer: No
SRM customer: No
Strategic: No
3. What is the nature and description of the request?
Customer want to define specific JNDI bindings from management console.
Through the management interface, the Profile ==> Container ==> Naming does not show up.
4. Why does the customer need this? (List the business requirements here)
Customer dont want to use CLI command for this,running CLI command remotely means there is a component deployed on remote machine.
There are several dependencies on this like Java being the biggest one, network...etc
customer want to perform all task from admin console only.
5. How would the customer like to achieve this? (List the functional requirements here)
Add "Naming" field(like EJB 3, EE,..etc) under "Profile ==> Container" in management console to specify JNDI bindings.
6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
TODO
9. Is the sales team involved in this request and do they have any additional input?
10. List any affected packages or components.
JBoss Admin console
11. Would the customer be able to assist in testing this functionality if implemented?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2446) invalid value for backup-group-name when it is undefined
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2446?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-2446:
------------------------------
Summary: invalid value for backup-group-name when it is undefined (was: invalid value for backup-group-name)
> invalid value for backup-group-name when it is undefined
> --------------------------------------------------------
>
> Key: WFLY-2446
> URL: https://issues.jboss.org/browse/WFLY-2446
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMS
> Affects Versions: 8.0.0.Beta1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.CR1
>
>
> In the messaging configuration, the backup-group-node modelNode is passed directly to the HornetQ configuration without checking whether it is defined.
> If it is not undefined, the hornetq configuration will use the "undefined" string as the backup group name instead of returning a null value
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2446) invalid value for backup-group-name
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-2446:
---------------------------------
Summary: invalid value for backup-group-name
Key: WFLY-2446
URL: https://issues.jboss.org/browse/WFLY-2446
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JMS
Affects Versions: 8.0.0.Beta1
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 8.0.0.CR1
In the messaging configuration, the backup-group-node modelNode is passed directly to the HornetQ configuration without checking whether it is defined.
If it is not undefined, the hornetq configuration will use the "undefined" string as the backup group name instead of returning a null value
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2305) add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2305:
-----------------------------------------------
Darran Lofthouse <darran.lofthouse(a)redhat.com> made a comment on [bug 1019264|https://bugzilla.redhat.com/show_bug.cgi?id=1019264]
Please DO NOT document --silent=true as a valid option.
The only reason for adding support for this option is users are not reading the current help text showing the valid options and are then getting caught out when they use an invalid form of this option - for that reason we are unofficially accepting it.
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2305
> URL: https://issues.jboss.org/browse/WFLY-2305
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Affects Versions: 8.0.0.Beta1
> Environment: WildFly snapshot of master 15-oct-2013
> Reporter: Tom Fonteyne
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months